lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <CANDhNCoLJ0YJUuQY=e0OfB05wbs7qvpwfnSVhQWt6Zkeo6sWrA@mail.gmail.com> Date: Mon, 3 Oct 2022 10:47:11 -0700 From: John Stultz <jstultz@...gle.com> To: Qais Yousef <qais.yousef@....com> Cc: LKML <linux-kernel@...r.kernel.org>, "Connor O'Brien" <connoro@...gle.com>, John Dias <joaodias@...gle.com>, Rick Yiu <rickyiu@...gle.com>, John Kacur <jkacur@...hat.com>, Chris Redpath <chris.redpath@....com>, Abhijeet Dharmapurikar <adharmap@...cinc.com>, Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>, Juri Lelli <juri.lelli@...hat.com>, Vincent Guittot <vincent.guittot@...aro.org>, Dietmar Eggemann <dietmar.eggemann@....com>, Steven Rostedt <rostedt@...dmis.org>, Thomas Gleixner <tglx@...utronix.de>, kernel-team@...roid.com, "J . Avila" <elavila@...gle.com> Subject: Re: [RFC PATCH v3 2/3] sched: Avoid placing RT threads on cores handling long softirqs On Mon, Oct 3, 2022 at 9:55 AM John Stultz <jstultz@...gle.com> wrote: > On Wed, Sep 28, 2022 at 5:55 AM Qais Yousef <qais.yousef@....com> wrote: > > On 09/21/22 01:25, John Stultz wrote: > > > @@ -1641,9 +1683,10 @@ select_task_rq_rt(struct task_struct *p, int cpu, int flags) > > > * requirement of the task - which is only important on heterogeneous > > > * systems like big.LITTLE. > > > */ > > > - test = curr && > > > - unlikely(rt_task(curr)) && > > > - (curr->nr_cpus_allowed < 2 || curr->prio <= p->prio); > > > + may_not_preempt = !task_may_preempt(curr, cpu); > > > + test = (curr && (may_not_preempt || > > > + (unlikely(rt_task(curr)) && > > > + (curr->nr_cpus_allowed < 2 || curr->prio <= p->prio)))); > > > > I think this is unnecesary if you create new rt_task_fits_cpu() and ... > > > > > > > > if (test || !rt_task_fits_capacity(p, cpu)) { > > > > ... replace the call to rt_task_fits_capacity() with the new > > rt_task_fits_cpu()? > > > But is that really the same logic? Above we're doing: > if ((!task_may_preempt(curr, cpu)|| <other stuff >) || > !rt_task_fits_capacity(p, cpu)) > > And you're suggestion switching it to > if (<other stuff> || !rt_task_fits_cpu(p, cpu)) > which would expand to: > if( <other stuff > || !(task_may_preempt(p, cpu) && > rt_task_fits_capacity(p, cpu))) > > I worry we would be skipping the part where we compare against curr. Ignore this bit, I've not finished my coffee. I was mixing up an earlier version of the patch where the task passed in to task_may_preempt() was compared with the ksoftirqd (which didn't seem right), and I've since switched it to comparing curr on the cpu with the ksoftirqd, making the task passed in unused. I'm reworking this to be less confusing (renaming this to cpu_busy_with_softirqs()), and will try to take your larger suggestion here. thanks -john
Powered by blists - more mailing lists