[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <68f91fb233d5bf82e29cc5c6960a62863b297db3.camel@surriel.com>
Date: Mon, 09 May 2022 15:10:16 -0400
From: Rik van Riel <riel@...riel.com>
To: Josh Poimboeuf <jpoimboe@...nel.org>
Cc: Song Liu <song@...nel.org>, linux-kernel@...r.kernel.org,
live-patching@...r.kernel.org, mingo@...hat.com,
peterz@...radead.org, vincent.guittot@...aro.org,
jpoimboe@...hat.com, joe.lawrence@...hat.com, kernel-team@...com
Subject: Re: [RFC] sched,livepatch: call stop_one_cpu in
klp_check_and_switch_task
On Mon, 2022-05-09 at 11:00 -0700, Josh Poimboeuf wrote:
> On Mon, May 09, 2022 at 11:52:27AM -0400, Rik van Riel wrote:
> > Does this look like an approach that could work?
> >
> > @@ -315,6 +321,9 @@ static bool klp_try_switch_task(struct
> > task_struct *task)
> > case -EBUSY: /* klp_check_and_switch_task() */
> > pr_debug("%s: %s:%d is running\n",
> > __func__, task->comm, task->pid);
> > + /* Preempt the task from the second KLP switch
> > attempt. */
> > + if (klp_signals_cnt)
> > + stop_one_cpu(task_cpu(task),
> > kpatch_dummy_fn, NULL);
>
> I must be missing something, how is briefly preempting a kthread
> supposed to actually transition it? Won't it likely go back to
> running
> on the CPU before the next periodic klp_transition_work_fn() check?
>
That's the kind of feedback I was hoping for ;)
I looked around the code a little bit, and it seems
that only the idle tasks can transition to another KLP
while they are running?
That makes me wonder how the kworker thread that runs
the klp switching code transitions itself...
Should kernel threads that can use a lot of CPU have
something in their outer loop to transition KLPs,
just like the idle task does?
--
All Rights Reversed.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists