All of lore.kernel.org
 help / color / mirror / Atom feed
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, 21 Jan 2025 07:58:18 -0800	[thread overview]
Message-ID: <001201db6c1d$4a0c19c0$de244d40$@telus.net> (raw)
In-Reply-To: <20250121112140.GJ8385@noisy.programming.kicks-ass.net>

On 2025.01.21 03:22 Peter Zijlstra wrote:
>On Tue, Jan 21, 2025 at 09:49:08AM +0100, Peter Zijlstra wrote:
>
>>> I modified your tracing trigger thing in turbostat to this:
>> 
>> Shiny!
>> 
>> What turbostat invocation do I use? I think the last I had was:
>> 
>>   tools/power/x86/turbostat/turbostat --quiet --show Busy%,IRQ,Time_Of_Day_Seconds,CPU,usec --interval 1
>> 
>> I've started a new run of yes-vs-turbostate with the modified trigger
>> condition. Lets see what pops out.
>
> Ok, I have a trace.o
>
> So I see turbostat wake up on CPU 15, do its migration round 0-15 and
> when its back at 15 it prints the WHOOPSIE.
>
> (trimmed trace):
>
>             yes-1169    [015] dNh4.  4238.261759: sched_wakeup: comm=turbostat pid=1185 prio=100 target_cpu=015
>             yes-1169    [015] d..2.  4238.261761: sched_switch: prev_comm=yes prev_pid=1169 prev_prio=120 prev_state=R ==>
next_comm=turbostat next_pid=1185 next_prio=100
>    migration/15-158     [015] d..3.  4238.261977: sched_migrate_task: comm=turbostat pid=1185 prio=100 orig_cpu=15 dest_cpu=0
>    migration/0-20      [000] d..3.  4238.261991: sched_migrate_task: comm=turbostat pid=1185 prio=100 orig_cpu=0 dest_cpu=1
>     migration/1-116     [001] d..3.  4238.262003: sched_migrate_task: comm=turbostat pid=1185 prio=100 orig_cpu=1 dest_cpu=2
>     migration/2-25      [002] d..3.  4238.262018: sched_migrate_task: comm=turbostat pid=1185 prio=100 orig_cpu=2 dest_cpu=3
>     migration/3-122     [003] d..3.  4238.262031: sched_migrate_task: comm=turbostat pid=1185 prio=100 orig_cpu=3 dest_cpu=4
>     migration/4-31      [004] d..3.  4238.262044: sched_migrate_task: comm=turbostat pid=1185 prio=100 orig_cpu=4 dest_cpu=5
>     migration/5-128     [005] d..3.  4238.262057: sched_migrate_task: comm=turbostat pid=1185 prio=100 orig_cpu=5 dest_cpu=6
>     migration/6-37      [006] d..3.  4238.262071: sched_migrate_task: comm=turbostat pid=1185 prio=100 orig_cpu=6 dest_cpu=7
>     migration/7-134     [007] d..3.  4238.262084: sched_migrate_task: comm=turbostat pid=1185 prio=100 orig_cpu=7 dest_cpu=8
>     migration/8-43      [008] d..3.  4238.262097: sched_migrate_task: comm=turbostat pid=1185 prio=100 orig_cpu=8 dest_cpu=9
>     migration/9-140     [009] d..3.  4238.262109: sched_migrate_task: comm=turbostat pid=1185 prio=100 orig_cpu=9 dest_cpu=10
>    migration/10-49      [010] d..3.  4238.262123: sched_migrate_task: comm=turbostat pid=1185 prio=100 orig_cpu=10 dest_cpu=11
>    migration/11-146     [011] d..3.  4238.262136: sched_migrate_task: comm=turbostat pid=1185 prio=100 orig_cpu=11 dest_cpu=12
>    migration/12-55      [012] d..3.  4238.262150: sched_migrate_task: comm=turbostat pid=1185 prio=100 orig_cpu=12 dest_cpu=13
>    migration/13-152     [013] d..3.  4238.262164: sched_migrate_task: comm=turbostat pid=1185 prio=100 orig_cpu=13 dest_cpu=14
>    migration/14-62      [014] d..3.  4238.262177: sched_migrate_task: comm=turbostat pid=1185 prio=100 orig_cpu=14 dest_cpu=15
>             yes-1169    [015] d..2.  4238.262182: sched_switch: prev_comm=yes prev_pid=1169 prev_prio=120 prev_state=R+ ==>
next_comm=turbostat next_pid=1185 next_prio=100
>       turbostat-1185    [015] .....  4238.262189: __x64_sys_gettimeofday: WHOOPSIE!
>
> The time between wakeup and whoopsie 4238.262189-4238.261759 = .000430
> or 430us, which doesn't seem excessive to me.
>
> Let me go read this turbostat code to figure out what exactly the
> trigger condition signifies. Because I'm not seeing nothing weird here.

I think the anomaly would have been about 1 second ago, on CPU 15,
and before entering sleep.
But after the previous call to the time of day stuff.

Somewhere in this code:

                delta_platform(&platform_counters_even, &platform_counters_odd);
                compute_average(ODD_COUNTERS);
                format_all_counters(ODD_COUNTERS);
                flush_output_stdout();

Please know that I ran a couple of tests yesterday for a total of about 8 hours
and never got a measured interval time >= 10 mSec.
I was using kernel 6.13, which includes your 2 patches, and I tried a slight
modification to the turbostat command:

sudo ./turbostat --quiet --Summary --show Busy%,Bzy_MHz,IRQ,PkgWatt,PkgTmp,TSC_MHz,Time_Of_Day_Seconds,usec --interval 1 --out
/dev/shm/turbo.log

That allowed me to acquire more than my ssh session history limit of about 9000 lines (seconds) and also eliminated ssh
communications.
It was on purpose that I used RAM to write the log file to.



  reply	other threads:[~2025-01-21 15:58 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-29 22:51 [REGRESSION] Re: [PATCH 00/24] Complete EEVDF 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
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 [this message]
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='001201db6c1d$4a0c19c0$de244d40$@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.