[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220508204101.GB76023@worktop.programming.kicks-ass.net>
Date: Sun, 8 May 2022 22:41:01 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Rik van Riel <riel@...com>
Cc: Song Liu <songliubraving@...com>,
"song@...nel.org" <song@...nel.org>,
"joe.lawrence@...hat.com" <joe.lawrence@...hat.com>,
"jpoimboe@...hat.com" <jpoimboe@...hat.com>,
"mingo@...hat.com" <mingo@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Kernel Team <Kernel-team@...com>,
"live-patching@...r.kernel.org" <live-patching@...r.kernel.org>,
"vincent.guittot@...aro.org" <vincent.guittot@...aro.org>
Subject: Re: [RFC] sched,livepatch: call klp_try_switch_task in __cond_resched
On Sat, May 07, 2022 at 07:18:51PM +0000, Rik van Riel wrote:
> Huh, I just looked at that, and the x86 should_resched()
> only seems to check that we _can_ resched, not whether
> we should...
>
>
> /*
> * Returns true when we need to resched and can (barring IRQ state).
> */
> static __always_inline bool should_resched(int preempt_offset)
> {
> return unlikely(raw_cpu_read_4(__preempt_count) ==
> preempt_offset);
> }
>
> I wonder if that was intended, and why, or whether
> the x86 should_resched should also be checking for
> TIF_NEED_RESCHED?
No, it does what you think it should do, you're just getting confused by
the inverted PREEMPT_NEED_RESCHED bit :-)
Powered by blists - more mailing lists