linux-kernel - Re: [GIT PULL] sched_ext: Initial pull request for v6.11

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZqmVG9ZiktN6bnm0@slm.duckdns.org>
Date: Tue, 30 Jul 2024 15:36:27 -1000
From: Tejun Heo <tj@...nel.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, David Vernet <void@...ifault.com>,
	Ingo Molnar <mingo@...hat.com>, Alexei Starovoitov <ast@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [GIT PULL] sched_ext: Initial pull request for v6.11

Hello,

On Wed, Jul 24, 2024 at 10:52:21AM +0200, Peter Zijlstra wrote:
...
> So pick_task() came from the SCHED_CORE crud, which does a remote pick
> and as such isn't able to do a put -- remote is still running its
> current etc.
> 
> So pick_task() *SHOULD* already be considering its current and pick
> that if it is a better candidate than whatever is on the queue.
> 
> If we have a pick_task() that doesn't do that, it's a pre-existing bug
> and needs fixing anyhow.

Right, I don't think it affects SCX in any significant way. Either way
should be fine.

...
> > Yeah, this came up before. On UP, SCX either needs to call the balance
> > callback as that's where the whole dispatch logic is called from (which
> > makes sense for it as dispatching often involves balancing operations), or
> > SCX itself needs to call it directly in a matching sequence. Just enabling
> > balance callback on UP && SCX would be the cleanest.
> 
> Or make scx hard depend on SMP? Are there really still people using !SMP
> -- and I suppose more importantly, do we care?
> 
> I mean, they could always run an SMP kernel on their UP potato if they
> *really* feel they need this.

Maybe, but at the same time, it's also just some isolated cruft that enables
UP support, so both sides of the scale seem similarly light-weight? I lean
towards "why not support it?" but don't feel particularly strongly about it.

Thanks.

-- 
tejun