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

I have installed FreeBSD 13.1, 64bit on a laptop

AMD A9-9425
12GB Ram
1TB HDD with UFS

After normal installation, added Xorg and LXQT with SDDM.

For first experiment

kern.hz=500
kern.eventtimer.periodic=0
kern.sched.preempt_thresh=171

On boot I dont login into the Desktop environment at the SDDM login screen

On another terminal say tty1, I login as root and start htop and wait for 10mins leaving the system as it is or idle u can say.

The load average is

0.19 ... 0.15 ... 0.08

Then I change only
kern.eventtimer.periodic=1

reboot and follow same proceedure.

The load average is

0.10 ... 0.04 ... 0.01

clearly showing that at idle CPU load average is less when

kern.eventtimer.periodic=1

Attached screenshots
 

Attachments

  • 20230324_011935.jpg
    20230324_011935.jpg
    602.8 KB · Views: 74
  • 20230324_011902.jpg
    20230324_011902.jpg
    556.2 KB · Views: 76
I have installed FreeBSD 13.1, 64bit on a laptop

AMD A9-9425
12GB Ram
1TB HDD with UFS

After normal installation, added Xorg and LXQT with SDDM.

For first experiment

kern.hz=500
kern.eventtimer.periodic=0
kern.sched.preempt_thresh=171

On boot I dont login into the Desktop environment at the SDDM login screen

Is Xorg running at all by then?

On another terminal say tty1, I login as root and start htop and wait for 10mins leaving the system as it is or idle u can say.

Ok, a primitive experiment, without necessary detail:

Which kern.timecounter?
Which kern.eventtimer?
What C-states are allowed?

Are you running powerd? What cpu.0.freq at idle?

The load average is
0.19 ... 0.15 ... 0.08

Only appears to be ... instead run systat -vm, observing (as well as LA)

interrupt rates
context switches etc

Then I change only
kern.eventtimer.periodic=1
reboot and follow same proceedure.

The load average is
0.10 ... 0.04 ... 0.01

Appears to be ... yes that's closer to 'traditional' LA, but at what cost?

clearly showing that at idle CPU load average is less when
kern.eventtimer.periodic=1

Only _appears_ to be less; notice what's happened to interrupt rates, context switches and - if you can measure it - relative power consumption.

Read carefully most of:


Particularly the posts by Alexander Motin (mav@), the author of eventtimers (both man 4 plus more coding-level detail in man 9) from FreeBSD 9.1 or so.

In linux-speak, kern.eventtimer.periodic=1 is 'ticked' (here at 500Hz, maybe _per_cpu_) whereas kern.eventtimer.periodic=0 is 'tickless' or 'coalesced' event scheduling.

Which saves an enormous number of interrupts and perhaps 25% power, at the expense of what mav@ called 'a pretty number' (ono)

Good luck with your learning path with FreeBSD. Try to avoid odious comparisons with Linux, and prosper.
 
Did you get a baseline with all default values prior to running any "experiments"?
If not, then you have no basis for deciding "this is better".
 
Coming up with more details, though yes as of now its just primitive experiments trying to catch some low hanging fruit.

Since my posts and threads are moderated, takes time for me to post.
 
I'm still missing a clear answer to the simple question: Why?

So if it isn't broken, don't "fix" it.

As you keep specifically mentioning "desktop": tuning kern.sched.preempt_thresh up a bit is somewhat common among desktop users. Not because it's "better". It just prefers latency over throughput which often matches the expectation for typical desktop workloads better. And the price clearly is that with load >= 1, the machine will be able to do less CPU work in the same time.

Anything else, I still don't get the point. I mean, what's the point of measuring "idle load" (which is btw VERY questionable as soon as any services are active, which is common case on a desktop installation)? Using hardware timers in "periodic" mode of course avoids having to reprogram them every time, so a very very very little bit less work for the CPU. Reprogramming is most likely preferred for other reasons (the flexibility to be able to program it differently eacht time), which allows to optimize other things, which might be much more important than "idle load".

Please, take a moment and think about what exactly you're trying to achieve in the first place.
 
This 2011 Intel Whitepaper, entitled "Energy Efficient Platforms - Considerations for Application Software and Services", despite using then Windows XP tools for illustration, is a rich source of information at this level:


Much of mav@'s work on eventtimers and clocks reflects many such ideas.

It now works for me, despite you may notice in the PR above, I was quite fanatical about wanting 0.0 LA at idle.

"Low hanging fruit" this ain't ;)
 
will be editing my OP a bit ... 0.0 at idle isnt what I am looking for or not trying go draw or suggest any conclusions

but am posting my experimentation results more in fact many to follow.
 
Is Xorg running at all by then?
YES
Ok, a primitive experiment, without necessary detail:

Which kern.timecounter?
kern.timecounter.hardware TSC-low
Which kern.eventtimer?
LAPIC
What C-states are allowed?

hw.acpi.cpu.cx_lowest: C1

cx_supported: C1/1/0 C2/2/400

All tests done on AC power

When on battery power
hw.acpi.cpu.cx_lowest: C8

But when on battery power and then back on AC power still remains C8 (can someone explain why) rather than reverting to C1.


after restart and plugged in again becomes C1

cx_supported remains same in both cases.

is this a bug?

Are you running powerd?

YES, no changes to it. Stock install as it is.
 
Last edited by a moderator:

Right, explains non-zero LA in periodic mode.

kern.timecounter.hardware TSC-low

LAPIC

ok

hw.acpi.cpu.cx_lowest: C1

cx_supported: C1/1/0 C2/2/400

All tests done on AC power

Could use C2 with mostly unnoticeable delay, but ok.

When on battery power

hw.acpi.cpu.cx_lowest: C8

But when on battery power and then back on AC power still remains C8 (can someone explain why) rather than reverting to C1.

Yes, specify these as e.g. performance_cx_lowest=C1
economy_cx_lowest=C8
in rc.conf, whereupon AC / battery transitions set hw.acpi.cpu.cx_lowest accordingly.

after restart and plugged in again becomes C1

Yep, initial state.

cx_supported remains same in both cases.

Yep. That may change if you pick a different eventtimer, e.g. HPET, but I don't know about AMD.

powerd, ok. What cpu.0.freq at idle?
 
Last edited by a moderator:
powerd, ok. What cpu.0.freq at idle?
haven't found a way to check or powertop like utility ... powermon doesn't run says cpuctl not installed/loaded put it in loader.conf but no luck

missing linux-cpupower package in linux world or cpufrequtils

most I miss is the graphical applet on the taskbar to change the frequency and schedular as in attached screenshot.
 

Attachments

  • 20230325_113115.jpg
    20230325_113115.jpg
    463.7 KB · Views: 44
me: powerd, ok. What cpu.0.freq at idle?

haven't found a way to check or powertop like utility ... powermon doesn't run says cpuctl not installed/loaded put it in loader.conf but no luck

How did you install cpuctl, and how did you specify it in loader.conf (don't tell, show)

I haven't my 12.4 system to hand, but 'man cpuctl' to see if it works for AMD cpus too?

missing linux-cpupower package in linux world or cpufrequtils

most I miss is the graphical applet on the taskbar to change the frequency and schedular as in attached screenshot.

Makes me wonder why you want to leave Linux at all?

If you want to be here, drop comparisons and learn to hunt for relevant ports, of which there are thousands.

Freshports search is a good place to start, other folks will point to others, apart from the obvious 'pkg search', 'grep -r ... /usr/ports' or 'find /usr/ports ...'

Personally I get a lot of utility from GKrellM on KDE for a detailed system overview.

But more often I'll use e.g:
% sysctl -a | grep 'cpu.*.freq'
 
I haven't my 12.4 system to hand, but 'man cpuctl' to see if it works for AMD cpus too?
As per man page it supports amd64 cpus but not specified which make.

kldstat -v does not show cpuctl module which means its not compiled in, for default FreeBSD 13.1 installation
But more often I'll use e.g:
% sysctl -a | grep 'cpu.*.freq'
Attached screenshot. First two commands fired when system is on AC power and next two are fired when system is on battery powered.
 

Attachments

  • 20230326_232318.jpg
    20230326_232318.jpg
    473.2 KB · Views: 111
Last edited:
Yep.
This happens a lot; "how can I make my *nix system work/look more like Windows?"
That may look like the intention but is not. I am entering FREEBSD world positively with the intention of using it for one of my server requirements and also to check if it can be used as a desktop.
 
Yep.
This happens a lot; "how can I make my *nix system work/look more like Windows?"

Well I won't go quite as far as comparing Linux with Windows, but yes, the general principle of hunting for greener grass only gives rise to dissatisfaction.
 
  • Like
Reactions: mer
haven't found a way to check or powertop like utility ... powermon doesn't run says cpuctl not installed/loaded put it in loader.conf but no luck

Ah yes, powermon(8) is specifically only for Intel CPUs, SandyBridge and later including my IvyBridge T430s.

You'll have to find the AMD folks re AMD-specific utils, mostly only for low-level.

Still, cpuctl_load="YES" in loader.conf should have loaded cpuctl.ko, even if useless for this purpose.

One big difference FreeBSD vs Linux is that if you can't run "man <whatever>" then you should open a PR for <whatever>, it's in error.

I've admin'd a few Linux systems over the years, Debian mostly, and always found that frustrating, and 'info' a horror story.
 
You'll have to find the AMD folks re AMD-specific utils, mostly only for low-level.
does this mean I have to contact developers of FreeNSD who do AMD specific commits?
Still, cpuctl_load="YES" in loader.conf should have loaded cpuctl.ko, even if useless for this purpose.
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.
One big difference FreeBSD vs Linux is that if you can't run "man <whatever>" then you should open a PR for <whatever>, it's in error.
PR means problem request isnt it?
Next will try to now again get back to the experiments and posting results, in line with the thread topic.
 
One thing to note is that the powerd stuff / C-lowest may end up becoming obsolete once we get the hwpstate stuff on Intel chips (I imagine there will be an AMD equivalent at some point).

I only encountered it due to freezes on 20% of my X1 Carbons. It is relating to this:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253288

So you might find in a couple of years, these optimizations are a little redundant. This is good progress in terms of power management. 8+ hours instead of ~4.

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.
 
clearly showing that at idle CPU load average is less

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.

Here's a thread about that: https://forums.freebsd.org/threads/load-average-calculation.72066/
 
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.
So far, I thought load on Linux was exactly the same thing? (IOW, average length of the run-queue)?
This has nothing to do with CPU "load" and e.g. CPU power consumption.
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.
 
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.
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, or compiles something with many threads over multiple cores - it's one process that woke up, hence the load is "1".
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.
 
Back
Top