Re: [GIT PULL] Scheduler changes for v6.8

From: Linus Torvalds <torvalds@linux-foundation.org>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Qais Yousef <qyousef@layalina.io>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	 Ingo Molnar <mingo@kernel.org>,
	linux-kernel@vger.kernel.org,
	 Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	 Juri Lelli <juri.lelli@redhat.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	 Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	 Daniel Bristot de Oliveira <bristot@redhat.com>,
	Valentin Schneider <vschneid@redhat.com>
Subject: Re: [GIT PULL] Scheduler changes for v6.8
Date: Fri, 12 Jan 2024 12:30:18 -0800	[thread overview]
Message-ID: <CAHk-=wiwRb50-q6EFU9RgjxOXHC2=x_ddQ6yzWTs5ah0nVeXPw@mail.gmail.com> (raw)
In-Reply-To: <CAKfTPtBQZcDpiPMF2sjJopNueMe+Lv0cziPzAMAaxH1XbfHiUQ@mail.gmail.com>

Ok, so testing a bit more. On a working kernel, when I do an empty
"make" (which is the fast test I've used), it's all single-threaded
because it's just 'make' doing tons of stat calls and string
operations.

And "cat /proc/cpuinfo | grep MHz" shows a nice clear signal:

  ...
  cpu MHz : 2200.000
  cpu MHz : 2200.000
  cpu MHz : 4425.339
  cpu MHz : 2200.000
  ...

so it boosts up to the top boost frequency.

Without the revert, doing the same thing, what I see is very
different. It's all just

  ...
  cpu MHz : 2200.000
  cpu MHz : 2200.000
  cpu MHz : 2200.000
  cpu MHz : 2200.000
  ...

which certainly explains why it takes 45s rather than 22s to do a full
empty build.

Btw, the "full empty build" I do is literally just

    timestamp sh -c "make -j128 > ../makes"

where 'timestamp' is my stupid little wrapper program that just shows
elapsed time as the command is progressing (as opposed to "time",
which just shows it at the end).

Side note: that 4425.339 is very much the boost frequency, 'cpupower' reports

  $ cpupower frequency-info
  analyzing CPU 0:
    driver: acpi-cpufreq
    CPUs which run at the same hardware frequency: 0
    CPUs which need to have their frequency coordinated by software: 0
    maximum transition latency:  Cannot determine or is not supported.
    hardware limits: 2.20 GHz - 3.70 GHz
    available frequency steps:  3.70 GHz, 2.80 GHz, 2.20 GHz
    available cpufreq governors: conservative ondemand userspace
powersave performance schedutil
    current policy: frequency should be within 2.20 GHz and 3.70 GHz.
                  The governor "schedutil" may decide which speed to use
                  within this range.
    current CPU frequency: Unable to call hardware
    current CPU frequency: 2.20 GHz (asserted by call to kernel)
    boost state support:
      Supported: yes
      Active: no

and for all I know the scheduler got confused by the fact that it
thinks the hardware limits are 2.2-3.7 GHz. But the 3970X has a boost
frequency of 4.5GHz, and yes, I very much want it.

I will test Vincent's test-patch next.

                Linus