From: "Doug Smythies" <dsmythies@telus.net>
To: "'Peter Zijlstra'" <peterz@infradead.org>
Cc: <linux-kernel@vger.kernel.org>, <vincent.guittot@linaro.org>,
"'Ingo Molnar'" <mingo@kernel.org>, <wuyun.abel@bytedance.com>,
"Doug Smythies" <dsmythies@telus.net>
Subject: RE: [REGRESSION] Re: [PATCH 00/24] Complete EEVDF
Date: Tue, 14 Jan 2025 07:15:50 -0800 [thread overview]
Message-ID: <001501db6697$32633960$9729ac20$@telus.net> (raw)
In-Reply-To: <20250114105847.GC8385@noisy.programming.kicks-ass.net>
On 2025.01.14 02:59 Peter Zijlstra wrote:
> On Mon, Jan 13, 2025 at 12:03:12PM +0100, Peter Zijlstra wrote:
>> On Sun, Jan 12, 2025 at 03:14:17PM -0800, Doug Smythies wrote:
>>> means that there were 19 occurrences of turbostat interval times
>>> between 1.016 and 1.016999 seconds.
>>
>> OK, let me lower my threshold to 10ms and change the turbostat
>> invocation -- see if I can catch me some wabbits :-)
>
> I've had it run overnight and have not caught a single >10ms event :-(
O.K. thanks for trying.
For me, the probability of occurrence does vary:
After moving gettimeofday calls back to their original places
in the code I recompiled turbostat, and got:
Total: 9082 : Total >= 10 mSec: 24 ( 0.26 percent)
And 2 previous tests had significant differences
In probability of occurrence:
Total: 9071 : Total >= 10 mSec: 39 ( 0.43 percent)
Total: 9079 : Total >= 10 mSec: 128 ( 1.41 percent)
Whenever I try to obtain more information by eliminating
the --Summary directive in turbostat, I never get
a >= 10 mSec hit
I tried looking into the sleep lengths by themselves without
using turbostat, and never saw a 1 second requested sleep
be longer than requested by >= 1 mSec.
Regardless, the 2 patches seem to have solved the up to
6 seconds extra time between samples issue. The most
I have seen with all this testing as been 23 milliseconds.
next prev parent reply other threads:[~2025-01-14 15:15 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-29 22:51 Doug Smythies
2025-01-06 11:57 ` Peter Zijlstra
2025-01-06 15:01 ` Doug Smythies
2025-01-06 16:59 ` Peter Zijlstra
2025-01-06 17:04 ` Peter Zijlstra
2025-01-06 17:14 ` Peter Zijlstra
2025-01-07 1:24 ` Doug Smythies
2025-01-07 10:49 ` Peter Zijlstra
2025-01-06 22:28 ` Doug Smythies
2025-01-07 11:26 ` Peter Zijlstra
2025-01-07 15:04 ` Doug Smythies
2025-01-07 16:25 ` Doug Smythies
2025-01-07 19:23 ` Peter Zijlstra
2025-01-08 5:15 ` Doug Smythies
2025-01-08 13:12 ` Peter Zijlstra
2025-01-08 15:48 ` Doug Smythies
2025-01-09 10:59 ` Peter Zijlstra
2025-01-09 12:18 ` [tip: sched/urgent] sched/fair: Fix EEVDF entity placement bug causing scheduling lag tip-bot2 for Peter Zijlstra
2025-04-17 9:56 ` Alexander Egorenkov
2025-04-22 5:40 ` ll"RE: " Doug Smythies
2025-04-24 7:56 ` Alexander Egorenkov
2025-04-26 15:09 ` Doug Smythies
2025-01-10 5:09 ` [REGRESSION] Re: [PATCH 00/24] Complete EEVDF Doug Smythies
2025-01-10 11:57 ` Peter Zijlstra
2025-01-12 23:14 ` Doug Smythies
2025-01-13 11:03 ` Peter Zijlstra
2025-01-14 10:58 ` Peter Zijlstra
2025-01-14 15:15 ` Doug Smythies [this message]
2025-01-15 2:08 ` Len Brown
2025-01-15 16:47 ` Doug Smythies
2025-01-19 0:09 ` Doug Smythies
2025-01-20 3:55 ` Doug Smythies
2025-01-21 11:06 ` Peter Zijlstra
2025-01-21 8:49 ` Peter Zijlstra
2025-01-21 11:21 ` Peter Zijlstra
2025-01-21 15:58 ` Doug Smythies
2025-01-24 4:34 ` Doug Smythies
2025-01-24 11:04 ` Peter Zijlstra
2025-01-13 11:05 ` Peter Zijlstra
2025-01-13 16:01 ` Doug Smythies
2025-01-13 12:58 ` [tip: sched/urgent] sched/fair: Fix update_cfs_group() vs DELAY_DEQUEUE tip-bot2 for Peter Zijlstra
2025-01-12 19:59 ` [REGRESSION] Re: [PATCH 00/24] Complete EEVDF Doug Smythies
-- strict thread matches above, loose matches on Subject: below --
2024-07-27 10:27 Peter Zijlstra
2024-11-28 10:32 ` [REGRESSION] " Marcel Ziswiler
2024-11-28 10:58 ` Peter Zijlstra
2024-11-28 11:37 ` Marcel Ziswiler
2024-11-29 9:08 ` Peter Zijlstra
2024-12-02 18:46 ` Marcel Ziswiler
2024-12-09 9:49 ` Peter Zijlstra
2024-12-10 16:05 ` Marcel Ziswiler
2024-12-10 16:13 ` Steven Rostedt
2024-12-10 8:45 ` Luis Machado
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='001501db6697$32633960$9729ac20$@telus.net' \
--to=dsmythies@telus.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=vincent.guittot@linaro.org \
--cc=wuyun.abel@bytedance.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
Powered by JetHome