[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241008153232.YwZfzF0r@linutronix.de>
Date: Tue, 8 Oct 2024 17:32:32 +0200
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Peter Zijlstra <peterz@...radead.org>
Cc: 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
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…
- __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
Powered by blists - more mailing lists