Moved from Linux to FreeBSD desktop low level configuration experiments and results

[zirias@]

A load of 1 only means in the given timefrime (e.g. 1sec) is always one process that wants to run. Doesn't matter if that process only prints the time on your screen and uses next to no CPU time

That's correct and the reason I added the word "roughly".

You can easily have loads of 20+ and the CPUs are mostly idling because e.g. all those processes are mainly waiting for IO to finish.

That's not correct as processes blocked on I/O aren't in the run-queue. The "load" value gives you the average length over a time period, so the effect of processes that are scheduled and almost immediately blocked is much smaller than you think.

 

[smithi]

you are aware that load on unix (i.e. also BSD) and on linux are completely different things?
Load on BSD is *NOT* the amount of CPU-time/cycles used, but the number of processes that (wanted to) run over a given time period. This has nothing to do with CPU "load" and e.g. CPU power consumption.

No, the old descriptions no longer apply, see below.

So far, I thought load on Linux was exactly the same thing? (IOW, average length of the run-queue)?

It's often said to be that, but it seems fairly meaningless these days, since mav@ (re-?)wrote eventtimers(4) back c. 9.2, which gave rise to quite different behaviour of LA display.

See my post #2 and the PR therein for gory details, but for very low loads near 100% idle, LA is no good indication due to coalescing of timer interrupts at greatly lower frequency (with large power savings)

Of course you can run in kern.eventtimer.periodic=1 mode, for nice looking 0.0 LAs at idle, but (hw.ncpu * kern.hz) extra interrupts!

I wouldn't say "nothing". Processes that want to run normally get scheduled. So a load of exactly ncpu normally means the CPU is (roughly!) 100% busy. But indeed, that's not a direct relation.

Yes, and for just CPU usage it's direct enough, e.g. running stress -c 4 for just over 1 hour on an i5 2.6GHz T430s, LAs showed as 4.00 within a few minutes with each of 4 stress cmds showing ~100% CPU, overall 100% busy, but it took more than 15 minutes for the '5 minute' LA to show ~4, and the '15 minute' one only got to 3.9 after an hour.

(FWIW, running at nominal cpu freq 2601 ran 2 physical cores at turbo 3093 MHz for that long, only reaching ~72°C at fan speed 3820, i.e. a well- cooled system)

Anyway, on 12.x and 13.x at least, idle LA is closer to 0.0 than the bad old days of 0.6 being displayed at idle, as that PR explores.

For judging CPU only, it's again near enough to use for load monitoring decisions, within 0.2 or so. I've not explored stress' --io, --vm or --hdd modes WRT load avs.

 

[smithi]

Ok, managed to rescue the previous post, as you were ...

 

[smithi]

does this mean I have to contact developers of FreeNSD who do AMD specific commits?

No, but if you start a new topic, maybe turn on "AMD" and "CPU" tags to catch the attention of AMD experts. People long ago decided to look at this topic, or not.

Does this mean its not compiled in the kernel? Or the module wasnt installed as installer identified AMD process and decided cpuctl shouldn't be installed.

cpuctl is a standard FreeBSD module, see /boot/kernel/, but it's not in the GENERIC kernel, so load it once with
# kldload cpuctl
or every boot with
cpuctl_load="YES"
in /boot/loader.conf
(as a general principle; I only load it to run powermon)

Use kldstat to see kernel and all other loaded modules, and
kldstat -v | less to see modules already in kernel, plus details of loaded ones.

PR means problem request isnt it?

Yes, problem report actually.

Don't hesitate to start a fresh forums thread when older ones veer off your topic ...

 

[sagsaw]

That said, I believe the OPs attempt to lower power consumption is always useful. Perhaps they can update the wiki page if they do find anything very relevant.

One place where I found some power savings could happen is when on AC power and powerd on. Less heat produced, less fan running, less noise.

performance_cx_lowest="Cmax"

Added this in rc.conf

Found CPU entered C2 state more often.

Need to check the power gains but thats in detailed test.

Again rest all is default values stock install, nothing changed.

 

[smithi]

One place where I found some power savings could happen is when on AC power and powerd on. Less heat produced, less fan running, less noise.

performance_cx_lowest="Cmax"
Added this in rc.conf

And economy_cx_lowest also, I presume?

Found CPU entered C2 state more often.

Indeed, about 20 times more often, 5% vs 95%

Need to check the power gains but thats in detailed test.

Again rest all is default values stock install, nothing changed.

Yes, less heat, less fan, less noise may only save a watt or so, but a win in any case.

On some systems Cmax will go to C3 for greater savings, possibly only when running on battery.

~~~~~~~

PS: it would be better if you could copy all or selected parts of text screens, then paste into [code] ... [/code] blocks here, especially for people using a phone to access forums.

cheers, Ian

 

[sagsaw]

And economy_cx_lowest also, I presume?

Yes.

On some systems Cmax will go to C3 for greater savings, possibly only when running on battery.

On my system as is evident in screenshot, cx_supported does not show C3 though cx_lowest shows C8

~~~~~~~

PS: it would be better if you could copy all or selected parts of text screens, then paste into [code] ... [/code] blocks here, especially for people using a phone to access forums.

Not understood, normal text marked as code. I use phone for forums and its nicely formatted and wrapped display vertical only scrolling.


I think possibly I may have uncovered a bug. Details after one more test.

Possibly due to powerd and power_profile conflict as mentioned in manpages of powerd

If powerd is used with power_profile, theymay override each other.

In my default install both are present in /etc/rc.d with powerd enabled in rc.conf

 

[smithi]

On my system as is evident in screenshot, cx_supported does not show C3 though cx_lowest shows C8

You said that was on AC power. Is it the same on battery power? I said, 'on some systems'; e.g. my X200 (Core2Duo) shows C3 only on battery, while T430s (i5) shows C3 either way.

Not understood, normal text marked as code.

Code blocks don't wrap text, but maintain original format by allowing horizontal slide. It doesn't need to be 'code'.

In your case above, a 400kB image that is hard for me (at least, on my phone) to view and resize - and impossible to quote without manually typing it all in (!) - could be replaced by just a few kB of quotable text. Understood?

I think possibly I may have uncovered a bug. Details after one more test.

Possibly due to powerd and power_profile conflict as mentioned in manpages of powerd

If powerd is used with power_profile, theymay override each other.

In my default install both are present in /etc/rc.d with powerd enabled in rc.conf

So you could study /etc/rc.d/power_profile, and the default values in /etc/defaults/rc.conf for {performance,economy}_cpu_freq

Leaving at the default value "NONE" prevents the conflict, as you presumably have?

Otherwise a specified value will be set on power source transition, though usually powerd readjusts cpu.0.freq before long. Generally, only specify *_cpu_freq values when NOT using powerd.