From: Song Liu <song@kernel.org>
To: Joe Lawrence <joe.lawrence@redhat.com>
Cc: David Vernet <void@manifault.com>,
live-patching@vger.kernel.org,
open list <linux-kernel@vger.kernel.org>,
jpoimboe@redhat.com, pmladek@suse.com, jikos@kernel.org,
mbenes@suse.cz
Subject: Re: [PATCH] livepatch: Avoid CPU hogging with cond_resched
Date: Mon, 10 Jan 2022 17:49:38 -0800 [thread overview]
Message-ID: <CAPhsuW7O6br8BtAb0Tnx2aMJODfp5Rvxn-YABPUCuL1ofNPcyw@mail.gmail.com> (raw)
In-Reply-To: <4df1f9a0-3b26-903b-fe63-af5e75ed98d4@redhat.com>
On Mon, Jan 10, 2022 at 8:17 AM Joe Lawrence <joe.lawrence@redhat.com> wrote:
>
> On 1/7/22 11:46 AM, Song Liu wrote:
> > On Fri, Jan 7, 2022 at 6:13 AM Joe Lawrence <joe.lawrence@redhat.com> wrote:
> >>
> >> On 12/29/21 4:56 PM, David Vernet wrote:
> >>> For example, under certain workloads, enabling a KLP patch with
> >>> many objects or functions may cause ksoftirqd to be starved, and thus for
> >>> interrupts to be backlogged and delayed.
> >>
> >> Just curious, approximately how many objects/functions does it take to
> >> hit this condition? While the livepatching kselftests are more about
> >> API and kernel correctness, this sounds like an interesting test case
> >> for some of the other (out of tree) test suites.
> >
> > Not many patched functions. We only do small fixes at the moment. In the recent
> > example, we hit the issue with ~10 patched functions. Another version
> > with 2 to 3
> > patched function seems fine.
> >
> > Yes, I think this is an important test case.
> >
>
> Thanks, Song. If you can share any test setup details, I'll pass those
> along to our internal QE group. And once merged, we'll be adding this
> one to the list of backports for our distro.
We get this on shadow production traffic of our web service, which we cannot
recreate out of our data centers.
I tried to use iperf to generate traffic (among a few hosts), but it
doesn't work.
At the moment, I am not sure what's the easiest way to repro this.
Thanks,
Song
next prev parent reply other threads:[~2022-01-11 1:49 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-29 21:56 [PATCH] livepatch: Avoid CPU hogging with cond_resched David Vernet
2022-01-05 10:17 ` Miroslav Benes
2022-01-07 0:21 ` Song Liu
2022-01-07 8:17 ` Petr Mladek
2022-01-10 14:55 ` David Vernet
2022-01-07 13:03 ` Petr Mladek
2022-01-07 14:13 ` Joe Lawrence
2022-01-07 16:46 ` Song Liu
2022-01-10 16:16 ` Joe Lawrence
2022-01-11 1:49 ` Song Liu [this message]
2021-12-30 4:16 David Vernet
2021-12-31 23:05 ` Kumar Kartikeya Dwivedi
2022-01-03 16:04 ` Petr Mladek
2022-01-10 14:38 ` David Vernet
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=CAPhsuW7O6br8BtAb0Tnx2aMJODfp5Rvxn-YABPUCuL1ofNPcyw@mail.gmail.com \
--to=song@kernel.org \
--cc=jikos@kernel.org \
--cc=joe.lawrence@redhat.com \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mbenes@suse.cz \
--cc=pmladek@suse.com \
--cc=void@manifault.com \
/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).