mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Joe Lawrence <joe.lawrence@redhat.com>
To: Song Liu <song@kernel.org>
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 11:16:58 -0500	[thread overview]
Message-ID: <4df1f9a0-3b26-903b-fe63-af5e75ed98d4@redhat.com> (raw)
In-Reply-To: <CAPhsuW4Ua2hDs5WMtF0s_CQki-ZdYMvkU2s+Nc7Rvs=-D6WL=Q@mail.gmail.com>

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.

-- 
Joe


  reply	other threads:[~2022-01-10 16:17 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-29 21:56 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 [this message]
2022-01-11  1:49       ` Song Liu
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=4df1f9a0-3b26-903b-fe63-af5e75ed98d4@redhat.com \
    --to=joe.lawrence@redhat.com \
    --cc=jikos@kernel.org \
    --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=song@kernel.org \
    --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

all inboxes | Powered by JetHome®