[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2202e0d211338d7641046fd8f05608b0dbaf7f78.camel@fb.com>
Date: Mon, 9 May 2022 01:07:50 +0000
From: Rik van Riel <riel@...com>
To: "peterz@...radead.org" <peterz@...radead.org>
CC: "joe.lawrence@...hat.com" <joe.lawrence@...hat.com>,
"song@...nel.org" <song@...nel.org>,
Song Liu <songliubraving@...com>,
"jpoimboe@...hat.com" <jpoimboe@...hat.com>,
"mingo@...hat.com" <mingo@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"live-patching@...r.kernel.org" <live-patching@...r.kernel.org>,
Kernel Team <Kernel-team@...com>,
"vincent.guittot@...aro.org" <vincent.guittot@...aro.org>
Subject: Re: [RFC] sched,livepatch: call klp_try_switch_task in __cond_resched
On Sun, 2022-05-08 at 22:41 +0200, Peter Zijlstra wrote:
>
> No, it does what you think it should do, you're just getting confused
> by
> the inverted PREEMPT_NEED_RESCHED bit :-)
Fair enough, that makes sense! Thanks for pointing that out.
That is a very clever optimization.
I suppose that should_resched() check is also something that
KLP could use by periodically poking tasks that get stuck in
the KLP transition (and are running) by simply calling
set_preempt_need_resched(), after which that klp_patch_pending()
check can happen only in the __cond_resched() path where we
already call preempt_schedule_common() anyway?
Is that something that would work, and be low enough overhead
in the general case to be acceptable?
Powered by blists - more mailing lists