What is sysctl kern.sched.preempt_thresh

There's some relevant discussion here (an old thread, but still pretty interesting) that I found at one point when I was googling this stuff:

Quoting from there:
If I recall
correctly the most loud supporters of the notion that SCHED_BSD is faster
than SCHED_ULE are using more threads than there are cores, causing CPU core
contention and more importantly unevenly distributed runtimes among threads,
resulting in suboptimal execution times for their programs.

Okay, so the really serious issue is indeed the one that I did accidentially run into and consequentially have fixed.
Cool, the number of known and discussed issues where only I have a working fix (and nobody wants it) is increasing (IPv6 inflight refragmentation would be the latest addition to that list). :)
 
  • Like
Reactions: mer
Quoting from there:


Okay, so the really serious issue is indeed the one that I did accidentially run into and consequentially have fixed.
Cool, the number of known and discussed issues where only I have a working fix (and nobody wants it) is increasing (IPv6 inflight refragmentation would be the latest addition to that list). :)
I understand your frustration. Ignorance is not a good thing. And the argument that someone has researched about this and therefore you cannot suggest changes.

If one of the developers of the ULE sees this please take a look on the patch PMc did provide way earlier in this thread.
 
There's some relevant discussion here (an old thread, but still pretty interesting) that I found at one point when I was googling this stuff:


I used to use kern.sched.preempt_thresh=224 as frequently recommended, but reverted to the default quite a while ago without really noticing any detrimental effects. For the last few days I've been trying 121 which (also) seems to work well on my system where I only use a window manager (cwm).

EDIT: Just for some additional context since ymmv depending on specs:

paul@zoo-FreeBSD ~ $ neofetch

...
CPU: Intel i5-9400F (6) @ 2.900GHz
GPU: GK208B [GeForce GT 710]
Memory: 3226MiB / 16274MiB

(Re-edited for bad formatting).
As you said that thread is old. And yes there are most likely workloads where the old scheduler is faster. And if you want you can use it. But I still believe that there is a reason the ULE scheduler is the default.
 
I understand your frustration.
No, I'm absolutely not frustrated. You know, if that thing would be committed, then some committer would claim the merits for it.

Furthermore, getting something committed appears to be an infinite amount of buerocracy, where you are forced onto your knees (just like Alfred tries to do with Uthred in TheLastKingdom), as if you would receive a gratefulness by being allowed to fix the bugs other complain about.
 
No, I'm absolutely not frustrated. You know, if that thing would be committed, then some committer would claim the merits for it.

Furthermore, getting something committed appears to be an infinite amount of buerocracy, where you are forced onto your knees (just like Alfred tries to do with Uthred in TheLastKingdom), as if you would receive a gratefulness by being allowed to fix the bugs other complain about.
Hi, good to know you are not frustrated :)

That is the one bad thing about the BSD license, that they can take your code and claim it without any mentioning. At least you should acknowledged for your contribution. On the other hand, If they used it a problem you experience is solved. although you probably uses the patch yourself. So solved for you anyway :)
 
I'm guessing the patch applies cleanly to a lot of kernel versions. Looks like it was against 12.2, I looked t 13-stable git repo earlier today and it looked like it would apply cleanly. Did not look at 14.

BSD License: they can take your code, use it, they cannot blame you if something goes wrong, but I don't think they can claim it as theirs. At one point I think the BSD license actually listed all the copyright holders, but current version does not. So PMc would own the copyright to his patch, a good committer would probably reference the source of the patch, who found the bug, etc.

My opinion on the "why ULE is the default": The hardware. If you look at the history, the BSD scheduler was really written for uniprocessor systems, with a different workload in mind. Take the lowest end consumer laptop from say Dell, it has multiple cores, mutiple threads so a lot more CPU than used to be. ULE was designed from the ground up for modern CPU, so SMP, multi cores, HTT, all the fun stuff that you would only find on an old SGI machine or some of the higher end SPARCs. Instead of trying to backfit all that into the BSD scheduler, it got a rewrite, which is a good thing.
But there has been a lot of time, a lot of machines, a lot of different workloads that maybe the default values and corner cases in ULE need to be revisted.
I believe there are still uses for the BSD scheduler, a lot of documentation talk about embedded, smaller footprint, etc.

Anyway, this has actually been one of the best scheduler threads I've read/participated in. Just discussion, suggestions, no finger pointing.
 
BSD License: they can take your code, use it, they cannot blame you if something goes wrong, but I don't think they can claim it as theirs. At one point I think the BSD license actually listed all the copyright holders, but current version does not. So PMc would own the copyright to his patch, a good committer would probably reference the source of the patch, who found the bug, etc.
That was always the case with BSD. As this was originally created by UCB, it had to be considered a common public effort that belongs to all people. And that is quite cool, because it implicitely means "for the greater good of mankind". It is what science originally was meant to be for. (But a lot of things have changed in the last 20 years regarding that.)

Now with a software of that size it is obvious that a lot of people will come along like "i have coded this and that cool feature and I want it included into the source." So it is obvious that thorough scrutiny is necessary in deciding what should go into the product and what shouldn't.
But, bugfixes were always something different, because it is not a question that bugs should be fixed. So there was always a fast-lane for bugfixes - and with some packages (e.g. sendmail) it might take less than 24 hours from sending in a bugfix to having it appear in HEAD.

This has all changed with the advent of so-called "security". Now the fast-lane is entirely reserved for "security". And all the people want security - no matter if it does them any good or not or not even concern them at all - they always want the newest security. So first and foremost of all there is security, then come new feature discussions, and finally fixing bugs (the classic QA, with the word "quality" in it) has apparently been abandoned entirely. In the best case bugfixes are treated like feature request, that is, the bugfixer must legitimate and explain why it would be desireable to fix bugs.

So, I think, anybody from the 80's or 90's, when looking at what we are doing today (and this is not limited to software development only), would be reminded of Dr. Tarr and Prof. Fether.
 
That was always the case with BSD. As this was originally created by UCB, it had to be considered a common public effort that belongs to all people. And that is quite cool, because it implicitely means "for the greater good of mankind". It is what science originally was meant to be for. (But a lot of things have changed in the last 20 years regarding that.)

Now with a software of that size it is obvious that a lot of people will come along like "i have coded this and that cool feature and I want it included into the source." So it is obvious that thorough scrutiny is necessary in deciding what should go into the product and what shouldn't.
But, bugfixes were always something different, because it is not a question that bugs should be fixed. So there was always a fast-lane for bugfixes - and with some packages (e.g. sendmail) it might take less than 24 hours from sending in a bugfix to having it appear in HEAD.

This has all changed with the advent of so-called "security". Now the fast-lane is entirely reserved for "security". And all the people want security - no matter if it does them any good or not or not even concern them at all - they always want the newest security. So first and foremost of all there is security, then come new feature discussions, and finally fixing bugs (the classic QA, with the word "quality" in it) has apparently been abandoned entirely. In the best case bugfixes are treated like feature request, that is, the bugfixer must legitimate and explain why it would be desireable to fix bugs.

So, I think, anybody from the 80's or 90's, when looking at what we are doing today (and this is not limited to software development only), would be reminded of Dr. Tarr and Prof. Fether.
As in other places of human life and society's there are always room for improvement. But if no one mentions it it is less likely to happen.

I know the bsd license quite well. And yes it in principle a gift to humankind. And I like that thougth, and is the reason for me to use open suurce software in the first place.. But it should also mean that those who administer it should be open to others and let improvements happen from other people as well. But at the same time be aware of security among other things. If that is not happening it is a problem for the project (in this case FreeBSD).

But lets keep the thread on the subject: My recommendation for sysctl kern.sched.preempt_thresh is sysctl kern.sched.preempt_thresh=120 for desktop use.

Thanks to everyone who has contributed this far :)
 
That's interesting. Too technical for me to understand the details, but I've always wondered about this sysctl everyone seems to use with that same value of 224 while it's poorly documented and isn't even mentioned in the handbook. It definitely deserves better documentation.
 
my recommendation is kern.sched.preempt_thresh=224 ... otherwise mouseclicks are behind on my system (AMD Ryzen 7 3700X, 64GB ECC RAM, Nvidia GeForce GTX 1650, NVME)
 
my recommendation is kern.sched.preempt_thresh=224 ... otherwise mouseclicks are behind on my system (AMD Ryzen 7 3700X, 64GB ECC RAM, Nvidia GeForce GTX 1650, NVME)
Following recommendation upper I have set kern.sched.preempt_thresh=120. My system is an AMD FX-6300, 8Gb RAM, Nvidia GT610, SSD sata and I don't have any issue like yours. I am using FVWM. All is fast and responsive.
Before this thread I used kern.sched.preempt_thresh=224 for years and I haven't seen any difference for now for my desktop use.
 
I think a lot of what you see is based on what you do. Someone doing stuff with real time video/audio is more sensitive to stutters in a player, drops in a stream that someone writing code or simply browsing with Firefox. I also think that your specific hardware plays into "what is a good value".

For me, this thread has been a good test of "value X has been recommended for years, but value Y works a lot better for me. Why?"
Understanding the meaning/impact of the value on the scheduler and how it manifests in your typical workload is a key towards "what is the best value for me".
 
my recommendation is kern.sched.preempt_thresh=224 ... otherwise mouseclicks are behind on my system (AMD Ryzen 7 3700X, 64GB ECC RAM, Nvidia GeForce GTX 1650, NVME)
Do you have other kern.sched**** values in your syctl.conf ?? If so please disable them and test again
 
How does kern.hz affect
kern.sched.preempt_thresh?

In Linux mostly people use 100 as the interrupt frequency for server (ubuntu server edition does) 250 (default for debian based ones) for either or and 300 plus for desktop. Some distros use 1000 and xanmod custom performance kernel uses 500.
 
How does kern.hz affect
kern.sched.preempt_thresh?

In Linux mostly people use 100 as the interrupt frequency for server (ubuntu server edition does) 250 (default for debian based ones) for either or and 300 plus for desktop. Some distros use 1000 and xanmod custom performance kernel uses 500.
They are not related as I understand it. The interrupts gives a time slice of the cpu to the scheduler. Low numbers give high throughput, high numbers more interactivity (faster switching between processes, as it can happen more often).

The kern.sched.preempt_thresh value tells the scheduler witch processes should have what priority (and have cpu time). Read more about it in the previous posts in this thread. For most servers a value of 80 is good. For desktop a bit higher value (for me 120). Others suggest the very high value of 224. But for me that means to many processes wants time, so my system will react slower to my input on the desktop.

So in the end both values contribute to amount of throughput (the lower numbers), and interactivity (a bit higher). 1000mhz is what I used on linux when making studio recordings (I am a professional musician), and might be overkill for normal desktop.
 
Low numbers give high throughput, high numbers more interactivity (faster switching between processes, as it can happen more often).

I still want to draw a line between high throughput as in many system calls (such as a file- or webserver) and high throughput of userlevel programs such as CPU-bound scientific compute or multimedia encoding.

If I understand things right then the variable won't affect system call heavy loads at all (since the processes preempt themselves when they run a system call). Very long system calls like sendfile(2) are another matter, I have no idea whether they are preemptable and I want to change that.
 
If I understand things right then the variable won't affect system call heavy loads at all
Well, maybe indirectly? As I understood it so far (didn't check code), blocked processes will gain priority (lower number) over time, so will have a better chance to hit the threshold to preempt other processes once they're runnable again?
 
kern.sched.preempt_thresh=224

On my 13.1 FreeBSD system

I added the same in /boot/loader.conf but on reboot it still keeps the default 80 as the value when checked via

sysctl -a

whereas if i change kern.hz via /boot/loader.conf tue value changes.

Why does kern.sched.prempt_thresh not change?
 
kern.sched.preempt_thresh=224

On my 13.1 FreeBSD system

I added the same in /boot/loader.conf but on reboot it still keeps the default 80 as the value when checked via

sysctl -a

whereas if i change kern.hz via /boot/loader.conf tue value changes.

Why does kern.sched.prempt_thresh not change?
You have to write the value in /etc/sysctl.conf

BTW. Try with different values. High values are not always better. On my desktop I use kern.sched.preempt_thresh=120. You can read a lot about it through these pages. There are a lot of input.
 
You have to write the value in /etc/sysctl.conf

BTW. Try with different values. High values are not always better. On my desktop I use kern.sched.preempt_thresh=120. You can read a lot about it through these pages. There are a lot of input.
Thanks, I figured that out immediately after writing this and was just going to post success.

yes write it in /etc/sysctl.conf
 
I still want to draw a line between high throughput as in many system calls (such as a file- or webserver) and high throughput of userlevel programs such as CPU-bound scientific compute or multimedia encoding.
in addition to this setting, possibly

for a server i would use

kern.sched.preempt_thresh=80
kern.hz=100 and
kern.eventtimer.periodic=1 (disable tickless)

and if FreeBSD has PREMPTION types like Linux has none/voluntary/full

I would use none
 
Back
Top