kern.sched.preemp_tresh

bob2112 said:
So what does kern.sched.ule.interact actually do? And why does setting it to 0 or 100 'largely "turns off" any impact from interactivity-scoring' ?
Click to expand...
So if setting to 0 means nothing is interactive and 100 means everything is interactive, then my understanding is "if everything is equal, then it doesn't have any effect".
Like when your boss gives you 12 tasks you ask "which is highest priority" and the answer is "they are all the highest priority": that tells you none of them are the highest priority so you just "pick one" and start working on it.
 
bob2112 said:
I don't follow this. The last time I looked, interactivity was a percentage which was added to the nice value to get the priority; the priorities were spit between interactive and batch. Interactive levels were assigned to dedicated queues (one per priority) with the batch levels handled by a ring of queues that guaranteed batch tasks all got some time. So being interactive wasn't a purely boolean distinction because there were many levels handled in priority order.

So what does kern.sched.ule.interact actually do? And why does setting it to 0 or 100 largely turn off any impact from interactivity-scoring ?
Click to expand...

That fair, I I did hedge with largely turns off.

I was looking here: https://github.com/freebsd/freebsd-...5c5ea8337054897116/sys/kern/sched_ule.c#L1753

Code: 
    score = imax(0, sched_interact_score(td) + nice);
    if (score < sched_interact) {
        [...]
    } else {

If kern.sched.ule.interact is set to 0, the score tested here will never be < 0, and it will never put in the interactive priority ranges, or use the score to adjust priority. Everything will be treated as batch, and scheduled accordingly.

If kern.sched.ule.interact is set to 100, score will (in the absence of nice) typically be less than 100, so most user-space tasks will be put into the interactive priority ranges, and they will have a priority within the interactive range influenced by their score. A "very interactive" process won't get some of the special treatment vs. "somewhat interactive" that it would receive vs a "batch / non-interactive" process.

Basically having the threshold somewhere between 0 and 100 lets it further refine scheduling decisions to favor interactive processes, and the value relates to "just how interactive" (it may seem strange, but "sleeps more than it runs" is the sign for "interactive" as it implies waiting for input) a process has to act to get that special treatment.

Things like "do I preempt some other task running on a different processor to run me" are always answered "yes" if the waiting-to-be-scheduled process is interactive and the victim process is batch.
 
mer said:
So if setting to 0 means nothing is interactive and 100 means everything is interactive, then my understanding is "if everything is equal, then it doesn't have any effect".
Like when your boss gives you 12 tasks you ask "which is highest priority" and the answer is "they are all the highest priority": that tells you none of them are the highest priority so you just "pick one" and start working on it.
Click to expand...
Unless something has changed radically (which is possible), that's wrong. Making them all interactive doesn't mean that they all have the same priority, it means that the choice of which task runs next is based only on priority. This is similar to how the 4BSD scheduler works, and some people have claimed to get better interactive desktop performance from this.

The downside to only using priority is that the lower priority tasks can get starved of cpu time (just like idle priority tasks can); so to counter this ULE handles batch level tasks in a way that takes account of priority, but allows low priority tasks to go ahead of higher priority task eventually. In a heavily loaded system it's then possible for a desktop GUI process that just dips into the batch region to get stuck behind resource hog processes - even if they are "niced" resource hogs.
 
bob2112 said:
Unless something has changed radically (which is possible), that's wrong. Making them all interactive doesn't mean that they all have the same priority, it means that the choice of which task runs next is based only on priority. This is similar to how the 4BSD scheduler works, and some people have claimed to get better interactive desktop performance from this.
Click to expand...
Perhaps I didn't say it clearly enough.
Setting the sysctl to 0 or 100 is removing the "extra" from the calculation. Not "making them all interactive".

Schedule priority is "X + interactive score"
if you set "interactive score" to min (0) or max(100) you are removing/limiting the effect of the interactive score.
That is what Eric A. Borisch is saying up in post #20.
 
This actually makes a massive difference if you are recording audio with jack
it really helps with xruns

Code: 
kern.sched.ule.preempt_thresh=224

I have Carla (audio host for plugins) set up with the deepfilter-net ladspa plugin
and LSP plugins with a noise gate, parametric eq, multiband compressor, compressor and a limiter

Then using qjackctl i pipe the audio into obs studio using a jack input source
which give me much better audio for my mic than using the obs studio plugins

I previously did the same thing with Ardour
but Ardour is broken at the moment and you have to patch it which takes about 11 hours to build with Poudriere

And when i updated to the latest quarterly branch Ardour broke again

So i installed Carla

Note if you just search for Carla nothing shows up

Code: 
pkg search carla

But if you search for audio/carla it does show up

Code: 
[i] pkg search audio/carla
audio/carla                    Audio plugin host for Jack and PulseAudio

Carla install

Code: 
doas pkg install audio/carla
 
NapoleonWils0n said:
Note if you just search for Carla nothing shows up

pkg search carla
Click to expand...
Well, if you say you searched for Carla but actually typed in carla, then no results is currently the correct response as pkg-search(8) and companions (I'm expecting all) are by default case sensitive, for quite some time actually.
However, the documentation is lagging behind: PR 294639 and comment on commit. So the document changes have been committed to pkg - development but have not been included in pkg-2.7.5. It is allready included in ports-mgmt/pkg-devel version 2.7.99.3.
 
Carla was just capitalized as the name of the application

Note if you just search for Carla nothing shows up
Click to expand...

but not in the search

Code: 
pkg search carla

i was just making the point you have to search like this

Code: 
pkg search audio/carla

maybe i wasnt clear about that
 
NapoleonWils0n said:
Carla was just capitalized as the name of the application



but not in the search

Code: 
pkg search carla

i was just making the point you have to search like this

Code: 
pkg search audio/carla

maybe i wasnt clear about that
Click to expand...
But I just did:
Code: 
 pkg search Carla
Carla-2.6.0.a1.g20260319       Audio plugin host for Jack and PulseAudio

which I think is what Erichans was pointing out.
 
My bad

i always search using lowercase

Code: 
[i] Yes Master ? pkg search carla
[djwilcox@pollux ~/desktop]

[djwilcox@pollux ~/desktop]
[i] Yes Master ? pkg search audio/carla
audio/carla                    Audio plugin host for Jack and PulseAudio

[i] Yes Master ? pkg search Carla
Carla-2.6.0.a1.g20260319       Audio plugin host for Jack and PulseAudio
 
NapoleonWils0n said:
My bad

i always search using lowercase

Code: 
[i] Yes Master ? pkg search carla
[djwilcox@pollux ~/desktop]

[djwilcox@pollux ~/desktop]
[i] Yes Master ? pkg search audio/carla
audio/carla                    Audio plugin host for Jack and PulseAudio

[i] Yes Master ? pkg search Carla
Carla-2.6.0.a1.g20260319       Audio plugin host for Jack and PulseAudio
Click to expand...
And that usually works, but sometimes doesn't :)
 
Eric A. Borisch said:
The paper on sched_ule: https://www.usenix.org/legacy/event/bsdcon03/tech/full_papers/roberson/roberson.pdf

Worth reading before turning knobs.

See also sysctl -d kern.sched.ule, and, of course, the source.
Click to expand...
Erichans said:
mer said:
in one of the threads here there is a link to a presentation on ULE
Click to expand...
Thread: What is sysctl kern.sched.preempt_thresh; one of my link overviews
Click to expand...
Note that the original 2003 Roberson article, the FreeBSD journal article (2014) & the video presentation of Kirk McKusick (2020) are mostly about the ULE scheduler as it was when it was introduced as the default scheduler. Things have changed. Currently the ULE scheduler has, for example, no more calendar queue to guarantee fairness; this has been implemented in another way. There is now only one run queue per CPU. The state of the available schedulers and ULE as of 15.1:
 
You must log in or register to reply here.
Back
Top