What is sysctl kern.sched.preempt_thresh

mer said:
File a bug report, attach as a patch.
Click to expand...
Well, I do that usually when I get onto something that is specific to my installation, or might be difficult to notice. But this here is not difficult to notice. And it is not that I keep the matter fror me - I tell it publicly, here and on the lists.

There were recurring complaints on the lists, that there are certain problems with the scheduler, over years. There are generally responded with the flat answer: if you don't like the new scheduler, you are free to use the old one.
Then you have, further up, lists of literature, from people who claim that they have not only used the scheduler, but have done research on it. If these would have done a slight bit of their homework, instead of just writing nicely formatted papers, they would have noticed this.

So, if there is just no interest in serious, professional work, then I am not the guy who tries to push it by all means, for no own benefit.
 
The ULE scheduler is better then the previous one. But still not "perfect".
The following simple command can block my desktop interactivity which should not happen. I have the impression niceness is not honoured enough.
Code: 
/usr/bin/nice -n 15 /usr/sbin/idprio 23 /usr/local/bin/poudriere bulk
I'm lacking psychological knowledge but devs should be open to constructive substantiated critics.
 
PMc said:
Well, I do that usually when I get onto something that is specific to my installation, or might be difficult to notice. But this here is not difficult to notice. And it is not that I keep the matter fror me - I tell it publicly, here and on the lists.

There were recurring complaints on the lists, that there are certain problems with the scheduler, over years. There are generally responded with the flat answer: if you don't like the new scheduler, you are free to use the old one.
Then you have, further up, lists of literature, from people who claim that they have not only used the scheduler, but have done research on it. If these would have done a slight bit of their homework, instead of just writing nicely formatted papers, they would have noticed this.

So, if there is just no interest in serious, professional work, then I am not the guy who tries to push it by all means, for no own benefit.
Click to expand...
Sorry to hear your experience with the developers. No software is perfect and will always need improvements and bug fixing. If anyone says something else they are plain wrong. Even if they are well known. And suggesting replacing something imperfect with something they know is worse is simply stupid and ignorance.

That people have done research and academic testing is fine, but again not anything but ignorance of problems there is and always will be with any software. Again all software can be improved upon and should be over time. I can see from the changelog in main that there is less things happening than in most other areas. And there are a couple of important ones (load balancer, search for load, refactor/optimize cpu search). And then a handful of other things.

But I do miss (and that is what I could see your patch doing) a possibility to set the timer to a higher value than 1000 for realtime multimedia work. I would still suggest to contact Hans Peter Selasky. He is a nerdy person, musician and in one of his presentations on FreeBSD and sound told it was not quite good enough yet for realtime audio.

I plan in my next computer to have a lot of cores, so many that there most of the time simply will be one free. This will for sure reduce latency.
 
Alain De Vos said:
The ULE scheduler is better then the previous one. But still not "perfect".
The following simple command can block my desktop interactivity which should not happen. I have the impression niceness is not honoured enough.
Code: 
/usr/bin/nice -n 15 /usr/sbin/idprio 23 /usr/local/bin/poudriere bulk
I'm lacking psychological knowledge but devs should be open to constructive substantiated critics.
Click to expand...
I am currently testing your suggestion for kern.sched.preempt_thresh=120. And after removing a pair of other "optimizations" it seems to work just fine. And fulfilling my wish for the lowest possible value
 
  • Like
Reactions: mer
#kern.sched.slice=3
#kern.sched.interact=5
#vm.overcommit=2
#kern.ipc.shm_use_phys=1
#vfs.hirunningspace=33554432

in order to let the scheduler do its thing
 
  • Like
Reactions: mer
Hi again

Still running with kern.sched.preempt_thresh=120. And the desktop is responsive and fast.

Reenabled vm.overcommit=2 and vfs.hirunningspace=33554432 in sysctl.conf again. no issues.

Is everyone else happy with this. Or what have you experieced.
 
I've been running with preempt_thresh=121 for a little bit now (maybe a week or so) working fine for my desktop/daily usage. If watching a youtube in firefox on one tab and bring up another tab to watch, not autoplay, but basically select and download another youtube video, the first one playing has occasional pauses, similar to a dropped frame or two, but that's it. Audio stays fine in the first one, keyboard, mouse seem normal. I spent a day with it set to 120, but based on what I was seeing in top with most of my user processes at PRI 20, it caused a lot more glitches than the value of 121.
 
mer said:
I've been running with preempt_thresh=121 for a little bit now (maybe a week or so) working fine for my desktop/daily usage. If watching a youtube in firefox on one tab and bring up another tab to watch, not autoplay, but basically select and download another youtube video, the first one playing has occasional pauses, similar to a dropped frame or two, but that's it. Audio stays fine in the first one, keyboard, mouse seem normal. I spent a day with it set to 120, but based on what I was seeing in top with most of my user processes at PRI 20, it caused a lot more glitches than the value of 121.
Click to expand...
What is your hardware. What to use depends a lot on that. On my system no glitches what so ever.

Are you sure you do not have any other modifiactions to kern.sched. On my sytem my interactive foreground processes get a higher priority. Not everything I do, needs to have a high priority. But my foreground process (what I call interactive) is getting a higher priority by itself. When I stop having them they get lower priority after a few seconds. So the scheduler does what it should do.
 
Haven't tried disabling everything else yet.
kern.sched.steal_thresh=1 kern.sched.balance=0 kern.sched.balance_interval=1000 kern.sched.affinity=10000 kern.sched.preempt_thresh=121

Hardware is an older NUC, CPU is i3-4010U CPU @ 1.70GHz, dual core 16GB ram.
 
mer said:
Haven't tried disabling everything else yet.
kern.sched.steal_thresh=1 kern.sched.balance=0 kern.sched.balance_interval=1000 kern.sched.affinity=10000 kern.sched.preempt_thresh=121

Hardware is an older NUC, CPU is i3-4010U CPU @ 1.70GHz, dual core 16GB ram.
Click to expand...
Disabling the other tunables was the first thing I did. Otherwise I cannot test the scheduler in its own right.

So try it out. It will probably make a difference :)
 
  • Like
Reactions: mer
mer said:
So I'm running with kern.sched defaults except for preempt_thresh, have that set to 120. We'll see
Click to expand...
And maybe try with both 120 and 121 to see if that makes a difference. Your machine has limited CPU resources, so maximizing use of those might be your goal
 
  • Like
Reactions: mer
Actually my goal is usually "Did I wake up above ground today?" ;) For computers, "does it run fast enough, does it not crash, does it run the applications I need".
Basically, I'm a simple man, coffee, dogs, fishing.
 
So running with preempt_thresh at 120 and the rest of the kern.sched seems to be "good". An interesting thing of note is I've always gotten messages in Xorg.0.log about "event processing lagging" messages about the USB mouse. I'm still getting them, but at a lot slower rate
 
mer said:
kern.sched.steal_thresh=1 kern.sched.balance=0 kern.sched.balance_interval=1000 kern.sched.affinity=10000 kern.sched.preempt_thresh=121
Hardware is an older NUC, CPU is i3-4010U CPU @ 1.70GHz, dual core 16GB ram.
Click to expand...
What is the presumed effect of kern.sched.balance_interval=1000* (127 by default on my 12.3-RELEASE) when having deactivated the long term load balancer with kern.sched.balance=0 ?

What is the intended effect of kern.sched.balance=0 on your system with regard to your system's problematic behaviour?

___
* integer kern.sched.balance_interval: Average period in stathz ticks to run the long-term balancer
 
Erichans said:
What is the presumed effect of kern.sched.balance_interval=1000* (127 by default on my 12.3-RELEASE) when having deactivated the long term load balancer with kern.sched.balance=0 ?

What is the intended effect of kern.sched.balance=0 on your system with regard to your system's problematic behaviour?

___
* integer kern.sched.balance_interval: Average period in stathz ticks to run the long-term balancer
Click to expand...
Don't know exactly. These values came from somewhere on a mailing list or somewhere here.
My systems behavior isn't problematic for me.
 
mer said:
So running with preempt_thresh at 120 and the rest of the kern.sched seems to be "good". An interesting thing of note is I've always gotten messages in Xorg.0.log about "event processing lagging" messages about the USB mouse. I'm still getting them, but at a lot slower rate
Click to expand...
As I suggested you could try 121 again as well to see if there are even less problems with that. If so I might try it out as well. But the difference is more easy to feel on a slower system like yours. But the "recomended" value of 223 is probably to much in most places.
 
  • Like
Reactions: mer
larshenrikoern said:
As I suggested you could try 121 again as well to see if there are even less problems with that. If so I might try it out as well. But the difference is more easy to feel on a slower system like yours. But the "recomended" value of 223 is probably to much in most places.
Click to expand...
seems to be very little difference between 120 and 121 with my standard use. I'll probably test at some point with it at the default 80.
ETA
Agree that the 223/224 is probably too high.
 
mer said:
seems to be very little difference between 120 and 121 with my standard use. I'll probably test at some point with it at the default 80.
ETA
Agree that the 223/224 is probably too high.
Click to expand...
Go with the lowest setting that gives good and fluent speed. So Alain De Vos was right with his suggestion for his desktop. And I think kern.sched.preempt_thresh=120 will be my recommendation for the future.
 
  • Like
Reactions: mer
So running with defaults but kern.sched.preempt_thresh=120 for about a while, seems reasonable for my nominal use. Occasional pauses on mouse events when starting up 3 youtube videos (plus adblocker), but not objectionable.
 
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:

SCHED_ULE should not be the default

fa.freebsd.stable.narkive.com fa.freebsd.stable.narkive.com

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).
 
You must log in or register to reply here.
Back
Top