| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20240113010432.xe25lxqogxuvl72t@airbuntu>
Date: Sat, 13 Jan 2024 01:04:32 +0000
From: Qais Yousef <qyousef@...alina.io>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Vincent Guittot <vincent.guittot@...aro.org>,
Dietmar Eggemann <dietmar.eggemann@....com>,
Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Juri Lelli <juri.lelli@...hat.com>,
Steven Rostedt <rostedt@...dmis.org>,
Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
Daniel Bristot de Oliveira <bristot@...hat.com>,
Valentin Schneider <vschneid@...hat.com>
Subject: Re: [GIT PULL] Scheduler changes for v6.8
On 01/12/24 13:04, Linus Torvalds wrote:
> On Fri, 12 Jan 2024 at 12:49, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> >
> > All cores stay at 2.2GHz (ok, so there's noise, but we're
> > talking "within a couple of MHz of 2.2GHz").
>
> Note: that is true also when every CPU is fully loaded and I do a real
> full build.
That is odd. I can't see how the patch can cause this yet, could you try with
a different compiler if possible? It seems like some operation goes wrong and
we end up with util or one of the transformations becoming 0 or nearby.
I tried your steps and I see frequencies changing. I have gcc
11.4.0 by default on my system.
I usually use perfetto but it should be easy to see frequency updates from
power/cpu_frequency trace event.
echo 1 | sudo tee /sys/kernel/tracing/tracing_on
echo 1 | sudo tee /sys/kernel/tracing/events/power/cpu_frequency/enable
sudo cat /sys/kernel/tracing/trace
or
sudo cat /sys/kernel/tracing/trace_pipe
to clear the buffer and block on read
Or easier with trace-cmd
sudo trace-cmd record -e power/cpu_frequency $COMPILE_CMD
sudo trace-cmd report
If there's no idle time the frequency updates will stop once we reach highest
frequency.
When I run it I see 2.2GHz and 3.8GHz values only, with and without the patches
reverted.
<idle>-0 [017]5089547182905: cpu_frequency: state=2200000 cpu_id=17
<...>-77147 [015]5089548006123: cpu_frequency: state=3800000 cpu_id=15
<idle>-0 [004]5089553342808: cpu_frequency: state=3800000 cpu_id=4
<idle>-0 [003]5089566989667: cpu_frequency: state=2200000 cpu_id=3
rm-77149 [005]5089569246195: cpu_frequency: state=3800000 cpu_id=5
<idle>-0 [004]5089570419322: cpu_frequency: state=2200000 cpu_id=4
<idle>-0 [017]5089570826267: cpu_frequency: state=3800000 cpu_id=17
<idle>-0 [003]5089575702589: cpu_frequency: state=3800000 cpu_id=3
<idle>-0 [017]5089576045916: cpu_frequency: state=2200000 cpu_id=17
<idle>-0 [003]5089584007141: cpu_frequency: state=2200000 cpu_id=3
<idle>-0 [015]5089593025639: cpu_frequency: state=2200000 cpu_id=15
<idle>-0 [010]5089593661028: cpu_frequency: state=2800000 cpu_id=10
<idle>-0 [023]5089595181029: cpu_frequency: state=2200000 cpu_id=23
<...>-77153 [015]5089595202328: cpu_frequency: state=3800000 cpu_id=15
<idle>-0 [017]5089596112508: cpu_frequency: state=3800000 cpu_id=17
<idle>-0 [003]5089601227012: cpu_frequency: state=3800000 cpu_id=3
<idle>-0 [017]5089601303574: cpu_frequency: state=2200000 cpu_id=17
<idle>-0 [005]5089611995487: cpu_frequency: state=2200000 cpu_id=5
<idle>-0 [017]5089612446143: cpu_frequency: state=3800000 cpu_id=17
<idle>-0 [003]5089612461191: cpu_frequency: state=2200000 cpu_id=3
cc1-77159 [009]5089616006631: cpu_frequency: state=3800000 cpu_id=9
<idle>-0 [003]5089618213587: cpu_frequency: state=3800000 cpu_id=3
<idle>-0 [017]5089618245105: cpu_frequency: state=2200000 cpu_id=17
<idle>-0 [003]5089624066151: cpu_frequency: state=2200000 cpu_id=3
<idle>-0 [017]5089627031955: cpu_frequency: state=3800000 cpu_id=17
<idle>-0 [003]5089632148220: cpu_frequency: state=3800000 cpu_id=3
<idle>-0 [017]5089633114584: cpu_frequency: state=2200000 cpu_id=17
objcopy-77166 [023]5089635324796: cpu_frequency: state=3800000 cpu_id=23
<idle>-0 [003]5089636043349: cpu_frequency: state=2200000 cpu_id=3
<idle>-0 [018]5089636071762: cpu_frequency: state=2200000 cpu_id=18
<idle>-0 [017]5089636511027: cpu_frequency: state=3800000 cpu_id=17
<idle>-0 [003]5089638171879: cpu_frequency: state=3800000 cpu_id=3
build-77168 [019]5089640011393: cpu_frequency: state=3800000 cpu_id=19
<idle>-0 [017]5089652020092: cpu_frequency: state=2200000 cpu_id=17
<idle>-0 [004]5089653340503: cpu_frequency: state=3800000 cpu_id=4
<idle>-0 [004]5089654532595: cpu_frequency: state=2200000 cpu_id=4
<idle>-0 [003]5089656013393: cpu_frequency: state=2200000 cpu_id=3
<idle>-0 [004]5089666815072: cpu_frequency: state=3800000 cpu_id=4
<idle>-0 [011]5089697117342: cpu_frequency: state=3800000 cpu_id=11
cat-77170 [010]5089697219972: cpu_frequency: state=3800000 cpu_id=10
<idle>-0 [004]5089697313957: cpu_frequency: state=2200000 cpu_id=4
<idle>-0 [017]5089699129526: cpu_frequency: state=3800000 cpu_id=17
ln-77172 [016]5089699710505: cpu_frequency: state=3800000 cpu_id=16
<idle>-0 [022]5089700249275: cpu_frequency: state=2200000 cpu_id=22
<idle>-0 [023]5089700316449: cpu_frequency: state=2200000 cpu_id=23
<idle>-0 [009]5089700372223: cpu_frequency: state=2200000 cpu_id=9
This is what cpupower frequency-info returns on my system
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 - 4.67 GHz
available frequency steps: 3.80 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.80 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
To my understanding schedutil doesn't know about turbo frequencies but we can
read current freq via counters which I think /proc/cpuinfo uses them. The trace
events will only show 3.8GHz as that's what we know about, but /proc/cpuinfo
shows above 4GHz if I run a single threaded workload, similar to what you've
seen. Again with and without the patches reverted.
I have to say, I am on tip/sched/core still. I probably should switch to your
tree to make sure there are no unexpected differences that can affect
reproducibility.
Cheers
--
Qais Yousef
>
> So the "empty make" is just my quick test that happens to be
> single-threaded and should take just 20s. All my real builds slow down
> too, because all CPUs stay at the minimum frequency.
>
> And I just verified that Ingo's revert that only reverts two commits
> (commit 60ee1706bd11 in the tip tree), makes things work correctly for
> me.
>
> Not surprising, since the bisection clearly pointed at just commit
> 9c0b4bb7f6303c being the one that caused the issue, but I decided to
> just double-check anyway.
>
> So with that revert, for the single-threaded case I see 4GHz+ numbers
> (they spread from a single CPU to multiple CPUs once you run the
> benchmark a few times).
>
> And then when I run a full parallel build (rather than the
> single-threaded empty one), the frequencies drop to ~3.85GHz for the
> all-cpu case.
>
> Linus
Powered by blists - more mailing lists