Page MenuHomeFreeBSD

Fix powerd CPU usage calculation
AbandonedPublic

Authored by AMDmi3 on Mar 19 2015, 4:02 PM.
Tags
None
Referenced Files
Unknown Object (File)
Jan 22 2024, 9:04 PM
Unknown Object (File)
Jan 22 2024, 9:04 PM
Unknown Object (File)
Dec 31 2023, 1:14 PM
Unknown Object (File)
Dec 20 2023, 12:21 AM
Unknown Object (File)
Nov 21 2023, 4:16 AM
Unknown Object (File)
Oct 30 2023, 6:55 AM
Unknown Object (File)
Sep 16 2023, 7:27 AM
Unknown Object (File)
Sep 6 2023, 6:16 PM
Subscribers

Details

Summary

powerd calculates CPU usage incorrectly. First, it calculates usage as a sum of usage % of all cores, which, for example, for 4 core CPU gives a value in range [0; 400]. At the same time, powerd limits usage percent input by user (-i option) with 100. This is confusing and doesn't allow to set usage correctnly. So at the very least, *load = *load / ncpus is needed in read_usage_times().

However, it seems to me that the whole thing with summing core usage is incorrect. Imagine two cases:

  1. 4 core system, each core is 25% loaded.
  2. 4 core system, one core is 100% loaded.

In the first case, frequency can be safely lowered 4x without causing CPU hunger for processes. In the second, lowering freq will lead to performance degradation.

The sum of CPU usages is the same in both cases, so powerd will not distinguish these cases. Logic based on maximal core load seems more correct though.

This patch was not really tested.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

AMDmi3 retitled this revision from to Fix powerd CPU usage calculation.
AMDmi3 updated this object.
AMDmi3 edited the test plan for this revision. (Show Details)
AMDmi3 added reviewers: mav, brueffer, wblock.
mav requested changes to this revision.Mar 19 2015, 4:44 PM
mav edited edge metadata.

This is probably the fifth proposition of that kind. I am tired to explain it every time, I don't want to, but seems has to.

This is not a bug! This logic follows Intel performance optimization guide. The rationale behind this logic is to handle the case when several threads pipelining the work, waiting for each other. There may be situation when you have four threads on four CPUs, each doing 25% of request processing during 25% of CPU time, other time waiting for others. If in such situation you detect CPU load of 25% and stop frequency -- you will get proportional performance drop.

CPU frequency scaling just does not work well for random general purpose load on SMP system.

This revision now requires changes to proceed.Mar 19 2015, 4:44 PM

This is probably the fifth proposition of that kind. I am tired to explain it every time, I don't want to, but seems has to.

There would be no such problem if there was comment with proper explanation.

This is not a bug! This logic follows Intel performance optimization guide. The rationale behind this logic is to handle the case when several threads pipelining the work, waiting for each other. There may be situation when you have four threads on four CPUs, each doing 25% of request processing during 25% of CPU time, other time waiting for others. If in such situation you detect CPU load of 25% and stop frequency -- you will get proportional performance drop.

How come? Frequency decrease won't affect sleeping - threads in this example will just sleep less as they work more.

Though no, you are correct, however I don't see that as a common case. Well, the first problem I've mentioned still exists. See updated patch - either that, or top limit on -i should be removed.

AMDmi3 edited edge metadata.

Scale overall CPU usage into [0; 100]

In D2097#11, @AMDmi3 wrote:

Though no, you are correct, however I don't see that as a common case.

I think there could be some time of such cases: disk I/O going through the chain of user-level, ZFS, GEOM and CAM threads and then back; video playing switching between video played and Xorg...

In that case, the first problem I've mentioned is still the case. Either that, or high limit on -i should be removed.

Limit removed to allow what? Set target load level to 200%? But that would mean that single thread never makes system run full speed.

Hmm, also correct. Hats off to you!