[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAPhsuW7O6br8BtAb0Tnx2aMJODfp5Rvxn-YABPUCuL1ofNPcyw@mail.gmail.com>
Date: Mon, 10 Jan 2022 17:49:38 -0800
From: Song Liu <song@...nel.org>
To: Joe Lawrence <joe.lawrence@...hat.com>
Cc: David Vernet <void@...ifault.com>, live-patching@...r.kernel.org,
open list <linux-kernel@...r.kernel.org>, jpoimboe@...hat.com,
pmladek@...e.com, jikos@...nel.org, mbenes@...e.cz
Subject: Re: [PATCH] livepatch: Avoid CPU hogging with cond_resched
On Mon, Jan 10, 2022 at 8:17 AM Joe Lawrence <joe.lawrence@...hat.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@...hat.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
Powered by blists - more mailing lists