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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ