linux-kernel - Re: [PATCH 0/5] sched: Lazy preemption muck

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: <20241009084514.V-RzKZRm@linutronix.de>
Date: Wed, 9 Oct 2024 10:45:14 +0200
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Ankur Arora <ankur.a.arora@...cle.com>, tglx@...utronix.de,
	mingo@...nel.org, linux-kernel@...r.kernel.org,
	juri.lelli@...hat.com, vincent.guittot@...aro.org,
	dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
	mgorman@...e.de, vschneid@...hat.com, efault@....de
Subject: Re: [PATCH 0/5] sched: Lazy preemption muck

On 2024-10-09 10:02:02 [+0200], Peter Zijlstra wrote:
> > There are places such as __clear_extent_bit() or select_collect() where
> > need_resched() is checked and if 0 they loop again. For these kind of
> > users it would probably make sense to allow them to preempt themself.
> > We could also add a new function which checks both and audit all users
> > and check what would make sense base on $criteria.
> 
> Do we really need this -- wasn't the idea to have thing 'delay' until
> the actual NEED_RESCHED bit gets set?

Not sure. They asked for it and have a lock acquired. But I guess it
could make sense to do as much work as possible until they have finally
to go.
This what we used to have in the RT tree, I don't complain just compare
notes.

Is there any punishment from the scheduler if they get preempted vs
leave early? It is just the time slice they used up and become less
eligible next time?

Let me do some more testing, this looks good so far.

Sebastian