From: Peter Zijlstra <peterz@infradead.org>
To: Chenbo Lu <chenbo.lu@jobyaviation.com>
Cc: stable@vger.kernel.org, regressions@lists.linux.dev,
mingo@redhat.com, juri.lelli@redhat.com,
linux-kernel@vger.kernel.org, vschneid@redhat.com
Subject: Re: Performance Degradation After Upgrading to Kernel 6.8
Date: Wed, 20 Nov 2024 10:03:54 +0100 [thread overview]
Message-ID: <20241120090354.GE19989@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <CACodVevaOp4f=Gg467_m-FAdQFceGQYr7_Ahtt6CfpDVQhAsjA@mail.gmail.com>
On Tue, Nov 19, 2024 at 04:30:02PM -0800, Chenbo Lu wrote:
> Hello,
>
> I am experiencing a significant performance degradation after
> upgrading my kernel from version 6.6 to 6.8 and would appreciate any
> insights or suggestions.
>
> I am running a high-load simulation system that spawns more than 1000
> threads and the overall CPU usage is 30%+ . Most of the threads are
> using real-time
> scheduling (SCHED_RR), and the threads of a model are using
> SCHED_DEADLINE. After upgrading the kernel, I noticed that the
> execution time of my model has increased from 4.5ms to 6ms.
>
> What I Have Done So Far:
> 1. I found this [bug
> report](https://bugzilla.kernel.org/show_bug.cgi?id=219366#c7) and
> reverted the commit efa7df3e3bb5da8e6abbe37727417f32a37fba47 mentioned
> in the post. Unfortunately, this did not resolve the issue.
> 2. I performed a git bisect and found that after these two commits
> related to scheduling (RT and deadline) were merged, the problem
> happened. They are 612f769edd06a6e42f7cd72425488e68ddaeef0a,
> 5fe7765997b139e2d922b58359dea181efe618f9
And yet you failed to Cc Valentin, the author of said commits :/
> After reverting these two commits, the model execution time improved
> to around 5 ms.
> 3. I revert two more commits, and the execution time is back to 4.7ms:
> 63ba8422f876e32ee564ea95da9a7313b13ff0a1,
> efa7df3e3bb5da8e6abbe37727417f32a37fba47
>
> My questions are:
> 1.Has anyone else experienced similar performance degradation after
> upgrading to kernel 6.8?
This is 4 kernel releases back, I my memory isn't that long.
> 2.Can anyone explain why these two commits are causing the problem? I
> am not very familiar with the kernel code and would appreciate any
> insights.
There might be a race window between setting the tro and sending the
IPI, such that previously the extra IPIs would sooner find the newly
pushable task.
Valentin, would it make sense to set tro before enqueueing the pushable,
instead of after it?
next prev parent reply other threads:[~2024-11-20 9:03 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-20 0:30 Performance Degradation After Upgrading to Kernel 6.8 Chenbo Lu
2024-11-20 9:03 ` Peter Zijlstra [this message]
2024-11-20 9:13 ` Peter Zijlstra
2024-11-27 17:27 ` Valentin Schneider
2024-12-02 19:16 ` Chenbo Lu
2024-11-20 12:11 ` Greg KH
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=20241120090354.GE19989@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=chenbo.lu@jobyaviation.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=regressions@lists.linux.dev \
--cc=stable@vger.kernel.org \
--cc=vschneid@redhat.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