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: <87wmihdh3u.fsf@oracle.com>
Date: Tue, 08 Oct 2024 21:40:05 -0700
From: Ankur Arora <ankur.a.arora@...cle.com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: Peter Zijlstra <peterz@...radead.org>, 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, ankur.a.arora@...cle.com, efault@....de
Subject: Re: [PATCH 0/5] sched: Lazy preemption muck


Sebastian Andrzej Siewior <bigeasy@...utronix.de> writes:

> On 2024-10-07 09:46:09 [+0200], Peter Zijlstra wrote:
>> Hi!
>>
>> During LPC Thomas reminded me that the lazy preemption stuff was not there yet.
>>
>> So here goes, robot says it builds, and I checked both a regular and PREEMPT_RT
>> build boots and can change the mode.
>>
>> Please have a poke.
>
> While comparing this vs what I have:
> - need_resched()
>   It checked both (tif_need_resched_lazy() || tif_need_resched()) while
>   now it only looks at tif_need_resched().
>   Also ensured that raw_irqentry_exit_cond_resched() does not trigger on
>   lazy.
>   I guess you can argue both ways what makes sense, just noting…

I think we want need_resched() to be only tif_need_resched(). That way
preemption in lazy mode *only* happens at the user mode boundary.

If the scheduler wants to preempt imminently, it just sets (or upgrades to)
TIF_NEED_RESCHED.

> - __account_cfs_rq_runtime() and hrtick_start_fair()
>   Both have a resched_curr() instead of resched_curr_lazy(). Is this on
>   purpose?
>
> This is actually the main difference (ignoring the moving the RT bits
> and dynamic-sched). The lazy-resched is slightly different but it should
> do the same thing.
> I have also tracing and riscv bits which I port tomorrow, test and add
> to your pile.
>
> Sebastian


--
ankur