From: "Seth Forshee (DigitalOcean)" <sforshee@digitalocean.com>
To: Petr Mladek <pmladek@suse.com>
Cc: 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>,
Josh Poimboeuf <jpoimboe@kernel.org>,
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: Thu, 26 Jan 2023 15:12:35 -0600 [thread overview]
Message-ID: <Y9LswwnPAf+nOVFG@do-x1extreme> (raw)
In-Reply-To: <Y9KyVKQk3eH+RRse@alley>
On Thu, Jan 26, 2023 at 06:03:16PM +0100, Petr Mladek wrote:
> On Fri 2023-01-20 16:12:20, Seth Forshee (DigitalOcean) wrote:
> > We've fairly regularaly seen liveptches which cannot transition within kpatch's
> > timeout period due to busy vhost worker kthreads.
>
> I have missed this detail. Miroslav told me that we have solved
> something similar some time ago, see
> https://lore.kernel.org/all/20220507174628.2086373-1-song@kernel.org/
Interesting thread. I had thought about something along the lines of the
original patch, but there are some ideas in there that I hadn't
considered.
> Honestly, kpatch's timeout 1 minute looks incredible low to me. Note
> that the transition is tried only once per minute. It means that there
> are "only" 60 attempts.
>
> Just by chance, does it help you to increase the timeout, please?
To be honest my test setup reproduces the problem well enough to make
KLP wait significant time due to vhost threads, but it seldom causes it
to hit kpatch's timeout.
Our system management software will try to load a patch tens of times in
a day, and we've seen real-world cases where patches couldn't load
within kpatch's timeout for multiple days. But I don't have such an
environment readily accessible for my own testing. I can try to refine
my test case and see if I can get it to that point.
> This low timeout might be useful for testing. But in practice, it does
> not matter when the transition is lasting one hour or even longer.
> It takes much longer time to prepare the livepatch.
Agreed. And to be clear, we cope with the fact that patches may take
hours or even days to get applied in some cases. The patches I sent are
just about improving the only case I've identified which has lead to
kpatch failing to load a patch for a day or longer.
Thanks,
Seth
next prev parent reply other threads:[~2023-01-26 21:12 UTC|newest]
Thread overview: 36+ 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 17:21 ` Seth Forshee
2023-01-25 11:34 ` Petr Mladek
2023-01-25 16:57 ` Seth Forshee
2023-01-26 11:16 ` Petr Mladek
2023-01-26 11:49 ` Petr Mladek
2023-01-22 8:34 ` [PATCH 0/2] vhost: improve livepatch switching for heavily loaded " Michael S. Tsirkin
2023-01-26 17:03 ` Petr Mladek
2023-01-26 21:12 ` Seth Forshee (DigitalOcean) [this message]
2023-01-27 4:43 ` Josh Poimboeuf
2023-01-27 10:37 ` Peter Zijlstra
2023-01-27 12:09 ` Petr Mladek
2023-01-27 14:37 ` Seth Forshee
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 17:50 ` Seth Forshee
2023-01-30 18:18 ` Josh Poimboeuf
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 16:38 ` Josh Poimboeuf
2023-02-01 11:10 ` Mark Rutland
2023-02-01 16:57 ` Josh Poimboeuf
2023-02-01 17:11 ` Mark Rutland
2023-01-30 19:59 ` Josh Poimboeuf
2023-01-31 10:02 ` Peter Zijlstra
2023-01-27 20:02 ` Seth Forshee
2023-01-27 11:19 ` Petr Mladek
2023-01-27 14:57 ` Seth Forshee
2023-01-30 9:55 ` Petr Mladek
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=Y9LswwnPAf+nOVFG@do-x1extreme \
--to=sforshee@digitalocean.com \
--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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).