MIME-Version: 1.0
References: <20211229215646.830451-1-void@manifault.com> <1f1b9b01-cfab-8a84-f35f-c21172e5d64d@redhat.com>
In-Reply-To: <1f1b9b01-cfab-8a84-f35f-c21172e5d64d@redhat.com>
From:   Song Liu <song@kernel.org>
Date:   Fri, 7 Jan 2022 08:46:44 -0800
Message-ID: <CAPhsuW4Ua2hDs5WMtF0s_CQki-ZdYMvkU2s+Nc7Rvs=-D6WL=Q@mail.gmail.com>
Subject: Re: [PATCH] livepatch: Avoid CPU hogging with cond_resched
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
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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.

Song