[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <59a5840f-2754-4478-8c4d-ffca02b1ecf1@redhat.com>
Date: Tue, 16 Sep 2025 05:29:00 +0000 (UTC)
From: Gabriele Monaco <gmonaco@...hat.com>
To: "John B. Wyatt IV" <jwyatt@...hat.com>
Cc: linux-kernel@...r.kernel.org,
Anna-Maria Behnsen <anna-maria@...utronix.de>,
Thomas Gleixner <tglx@...utronix.de>,
Waiman Long <longman@...hat.com>, Tejun Heo <tj@...nel.org>,
Johannes Weiner <hannes@...xchg.org>,
Michal Koutný <mkoutny@...e.com>,
cgroups@...r.kernel.org,
"John B. Wyatt IV" <sageofredondo@...il.com>
Subject: Re: [PATCH v12 9/9] timers: Exclude isolated cpus from timer
migration
2025-09-15T20:51:21Z John B. Wyatt IV <jwyatt@...hat.com>:
> On Mon, Sep 15, 2025 at 04:59:30PM +0200, Gabriele Monaco wrote:
>
> Your patchset continues to pass when applied against v6.17-rc4-rt3 on a
> preview of RHEL 10.2.
>
> rtla osnoise top -c 1 -e sched:sched_switch -s 20 -T 1 -t -d 30m -q
>
> duration: 0 00:30:00 | time is in us
> CPU Period Runtime Noise % CPU Aval Max Noise Max Single HW NMI IRQ Softirq Thread
> 1 #1799 1799000001 3351316 99.81371 2336 9 400 0 1799011 0 23795
>
>> This effect was noticed on a 128 cores machine running oslat on the
>> isolated cores (1-31,33-63,65-95,97-127). The tool monopolises CPUs,
>> and the CPU with lowest count in a timer migration hierarchy (here 1
>> and 65) appears as always active and continuously pulls global timers,
>> from the housekeeping CPUs. This ends up moving driver work (e.g.
>> delayed work) to isolated CPUs and causes latency spikes:
>>
>
> If you do another version; you may want to amend the cover letter to include
> this affect can be noticed with a machine with as few as 20cores/40threads
> with isocpus set to: 1-9,11-39 with rtla-osnoise-top
>
> Tested-by: John B. Wyatt IV <jwyatt@...hat.com>
> Tested-by: John B. Wyatt IV <sageofredondo@...il.com>
>
Thanks John for testing again, I'll mention your results with the next version.
Cheers,
Gabriele
Powered by blists - more mailing lists