From: Peter Zijlstra <peterz@infradead.org>
To: Pan Deng <pan.deng@intel.com>
Cc: mingo@kernel.org, linux-kernel@vger.kernel.org,
tianyou.li@intel.com, tim.c.chen@linux.intel.com,
yu.c.chen@intel.com
Subject: Re: [PATCH v2 0/4] sched/rt: mitigate root_domain cache line contention
Date: Fri, 20 Mar 2026 13:50:02 +0100 [thread overview]
Message-ID: <20260320125002.GH3739106@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20260320095955.GQ3738786@noisy.programming.kicks-ass.net>
On Fri, Mar 20, 2026 at 10:59:55AM +0100, Peter Zijlstra wrote:
> On Mon, Jul 21, 2025 at 02:10:22PM +0800, Pan Deng wrote:
> > When running multi-instance FFmpeg workload in cloud environment,
> > cache line contention is severe during the access to root_domain data
> > structures, which significantly degrades performance.
> >
> > The SUT is a 2-socket machine with 240 physical cores and 480 logical
>
> What's a SUT?
>
> > CPUs. 60 FFmpeg instances are launched, each pinned to 4 physical cores
> > (8 logical CPUs) for transcoding tasks. Sub-threads use RT priority 99
> > with FIFO scheduling. FPS(frame per second) is used as score.
>
> So I think we can do some of this, but that workload is hilariously
> poorly configured.
>
> You're pinning things but not partitioning, why? If you would have
> created 60 partitions, one for each FFmpeg thingy, then you wouldn't
> have needed any of this.
>
> You're running at FIFO99 (IOW prio-0) and then claiming prio-0 is used
> more heavily than others... will d0h. What priority assignment scheme
> led to this? Is there a sensible reason these must be 99?
>
Also, you failed the most basic of tasks, Cc all the relevant people. I
would've hoped at least some of the 'reviewer' you had would've told you
about that.
Notably, Steve is the one that often looks after this RT stuff.
prev parent reply other threads:[~2026-03-20 12:50 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-21 6:10 [PATCH v2 0/4] sched/rt: mitigate root_domain cache line contention Pan Deng
2025-07-21 6:10 ` [PATCH v2 1/4] sched/rt: Optimize cpupri_vec layout to mitigate " Pan Deng
2026-03-20 10:09 ` Peter Zijlstra
2026-03-24 9:36 ` Deng, Pan
2026-03-24 12:11 ` Peter Zijlstra
2026-03-27 10:17 ` Deng, Pan
2026-04-02 10:37 ` Deng, Pan
2026-04-02 10:43 ` Peter Zijlstra
2026-04-08 10:16 ` Chen, Yu C
2026-04-09 11:47 ` Deng, Pan
2025-07-21 6:10 ` [PATCH v2 2/4] sched/rt: Restructure root_domain to reduce cacheline contention Pan Deng
2026-03-20 10:18 ` Peter Zijlstra
2025-07-21 6:10 ` [PATCH v2 3/4] sched/rt: Split root_domain->rto_count to per-NUMA-node counters Pan Deng
2026-03-20 10:24 ` Peter Zijlstra
2026-03-23 18:09 ` Tim Chen
2026-03-24 12:16 ` Peter Zijlstra
2026-03-24 22:40 ` Tim Chen
2025-07-21 6:10 ` [PATCH v2 4/4] sched/rt: Split cpupri_vec->cpumask to per NUMA node to reduce contention Pan Deng
2026-03-20 12:40 ` Peter Zijlstra
2026-03-23 18:45 ` Tim Chen
2026-03-24 12:00 ` Peter Zijlstra
2026-03-31 5:37 ` Chen, Yu C
2026-03-31 10:19 ` K Prateek Nayak
2026-04-02 3:15 ` Chen, Yu C
2026-04-02 4:41 ` K Prateek Nayak
2026-04-02 10:55 ` Peter Zijlstra
2026-04-02 11:06 ` K Prateek Nayak
2026-04-03 5:46 ` Chen, Yu C
2026-04-03 8:13 ` K Prateek Nayak
2026-04-07 20:35 ` Tim Chen
2026-04-08 3:06 ` K Prateek Nayak
2026-04-08 11:35 ` Chen, Yu C
2026-04-08 15:52 ` K Prateek Nayak
2026-04-09 5:17 ` K Prateek Nayak
2026-04-09 23:09 ` Tim Chen
2026-04-10 5:51 ` Chen, Yu C
2026-04-10 6:02 ` K Prateek Nayak
2026-04-08 9:25 ` Chen, Yu C
2026-04-08 16:47 ` Tim Chen
2026-03-20 9:59 ` [PATCH v2 0/4] sched/rt: mitigate root_domain cache line contention Peter Zijlstra
2026-03-20 12:50 ` Peter Zijlstra [this message]
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=20260320125002.GH3739106@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=pan.deng@intel.com \
--cc=tianyou.li@intel.com \
--cc=tim.c.chen@linux.intel.com \
--cc=yu.c.chen@intel.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