From: Seth Forshee <sforshee@kernel.org>
To: Petr Mladek <pmladek@suse.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Josh Poimboeuf <jpoimboe@kernel.org>,
Jason Wang <jasowang@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Jiri Kosina <jikos@kernel.org>, Miroslav Benes <mbenes@suse.cz>,
Joe Lawrence <joe.lawrence@redhat.com>,
virtualization@lists.linux-foundation.org, kvm@vger.kernel.org,
netdev@vger.kernel.org, live-patching@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] vhost: improve livepatch switching for heavily loaded vhost worker kthreads
Date: Fri, 27 Jan 2023 08:37:19 -0600 [thread overview]
Message-ID: <Y9Phn27nrVO/oOi+@do-x1extreme> (raw)
In-Reply-To: <Y9O+3jzH0PiG1qlJ@alley>
On Fri, Jan 27, 2023 at 01:09:02PM +0100, Petr Mladek wrote:
> There might actually be two possibilities why the transition fails
> too often:
>
> 1. The task might be in the running state most of the time. Therefore
> the backtrace is not reliable most of the time.
>
> In this case, some cooperation with the scheduler would really
> help. We would need to stop the task and check the stack
> when it is stopped. Something like the patch you proposed.
This is the situation we are encountering.
> 2. The task might be sleeping but almost always in a livepatched
> function. Therefore it could not be transitioned.
>
> It might be the case with vhost_worker(). The main loop is "tiny".
> The kthread probaly spends most of the time with processing
> a vhost_work. And if the "works" are livepatched...
>
> In this case, it would help to call klp_try_switch_task(current)
> in the main loop in vhost_worker(). It would always succeed
> when vhost_worker() is not livepatched on its own.
>
> Note that even this would not help with kPatch when a single
> vhost_work might need more than the 1 minute timout to get proceed.
>
> > diff --git a/kernel/livepatch/transition.c b/kernel/livepatch/transition.c
> > index f1b25ec581e0..06746095a724 100644
> > --- a/kernel/livepatch/transition.c
> > +++ b/kernel/livepatch/transition.c
> > @@ -9,6 +9,7 @@
> >
> > #include <linux/cpu.h>
> > #include <linux/stacktrace.h>
> > +#include <linux/stop_machine.h>
> > #include "core.h"
> > #include "patch.h"
> > #include "transition.h"
> > @@ -334,6 +335,16 @@ static bool klp_try_switch_task(struct task_struct *task)
> > return !ret;
> > }
> >
> > +static int __stop_try_switch(void *arg)
> > +{
> > + return klp_try_switch_task(arg) ? 0 : -EBUSY;
> > +}
> > +
> > +static bool klp_try_switch_task_harder(struct task_struct *task)
> > +{
> > + return !stop_one_cpu(task_cpu(task), __stop_try_switch, task);
> > +}
> > +
> > /*
> > * Sends a fake signal to all non-kthread tasks with TIF_PATCH_PENDING set.
> > * Kthreads with TIF_PATCH_PENDING set are woken up.
>
> Nice. I am surprised that it can be implemented so easily.
Yes, that's a neat solution. I will give it a try.
AIUI this still doesn't help for architectures without a reliable
stacktrace though, right? So we probably should only try this for
architectures which do have relaible stacktraces.
Thanks,
Seth
next prev parent reply other threads:[~2023-01-27 14:37 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-20 22:12 [PATCH 0/2] vhost: improve livepatch switching for heavily loaded vhost worker kthreads Seth Forshee (DigitalOcean)
2023-01-20 22:12 ` [PATCH 1/2] livepatch: add an interface for safely switching kthreads Seth Forshee (DigitalOcean)
2023-01-20 22:12 ` [PATCH 2/2] vhost: check for pending livepatches from vhost worker kthreads Seth Forshee (DigitalOcean)
2023-01-24 14:17 ` Petr Mladek
2023-01-24 14:17 ` Petr Mladek via Virtualization
2023-01-24 17:21 ` Seth Forshee
2023-01-25 11:34 ` Petr Mladek
2023-01-25 11:34 ` Petr Mladek via Virtualization
2023-01-25 16:57 ` Seth Forshee
2023-01-26 11:16 ` Petr Mladek
2023-01-26 11:16 ` Petr Mladek via Virtualization
2023-01-26 11:49 ` Petr Mladek
2023-01-26 11:49 ` Petr Mladek via Virtualization
2023-01-22 8:34 ` [PATCH 0/2] vhost: improve livepatch switching for heavily loaded " Michael S. Tsirkin
2023-01-22 8:34 ` Michael S. Tsirkin
2023-01-26 17:03 ` Petr Mladek
2023-01-26 17:03 ` Petr Mladek via Virtualization
2023-01-26 21:12 ` Seth Forshee (DigitalOcean)
2023-01-27 4:43 ` Josh Poimboeuf
2023-01-27 10:37 ` Peter Zijlstra
2023-01-27 10:37 ` Peter Zijlstra
2023-01-27 12:09 ` Petr Mladek
2023-01-27 12:09 ` Petr Mladek via Virtualization
2023-01-27 14:37 ` Seth Forshee [this message]
2023-01-27 16:52 ` Josh Poimboeuf
2023-01-27 17:09 ` Josh Poimboeuf
2023-01-27 22:11 ` Josh Poimboeuf
2023-01-30 12:40 ` Peter Zijlstra
2023-01-30 12:40 ` Peter Zijlstra
2023-01-30 17:50 ` Seth Forshee
2023-01-30 18:18 ` Josh Poimboeuf
2023-01-30 18:36 ` Mark Rutland
2023-01-30 18:36 ` Mark Rutland
2023-01-30 19:48 ` Josh Poimboeuf
2023-01-31 1:53 ` Song Liu
2023-01-31 10:22 ` Mark Rutland
2023-01-31 10:22 ` Mark Rutland
2023-01-31 16:38 ` Josh Poimboeuf
2023-02-01 11:10 ` Mark Rutland
2023-02-01 11:10 ` Mark Rutland
2023-02-01 16:57 ` Josh Poimboeuf
2023-02-01 17:11 ` Mark Rutland
2023-02-01 17:11 ` Mark Rutland
2023-01-30 19:59 ` Josh Poimboeuf
2023-01-31 10:02 ` Peter Zijlstra
2023-01-31 10:02 ` Peter Zijlstra
2023-01-27 20:02 ` Seth Forshee
2023-01-27 11:19 ` Petr Mladek
2023-01-27 11:19 ` Petr Mladek via Virtualization
2023-01-27 14:57 ` Seth Forshee
2023-01-30 9:55 ` Petr Mladek
2023-01-30 9:55 ` Petr Mladek via Virtualization
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y9Phn27nrVO/oOi+@do-x1extreme \
--to=sforshee@kernel.org \
--cc=jasowang@redhat.com \
--cc=jikos@kernel.org \
--cc=joe.lawrence@redhat.com \
--cc=jpoimboe@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mbenes@suse.cz \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=virtualization@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.