Re: Periodic rant about SCHED_ULE

FWIW, to eliminate "stuttering" for interactive use (desktop), changing 
defaults for either one of these work wonderfully on recent AMD system 
(AM4 5700G):

kern.sched.steal_thresh=1

or

kern.eventtimer.timer=HPET

My test case is autoscroll in firefox must be butter smooth, no freezes 
or jerks, and it works. So, maybe its worth tweaking some knobs to 
optimize particular workload, although how can one expect reproducible 
results with something like dnetc?


On 3/22/23 14:31, Matthias Andree wrote:
> Am 22.03.23 um 15:41 schrieb George Mitchell:
>> On 3/22/23 06:17, Matthias Andree wrote:
>>> Am 21.03.23 um 23:52 schrieb George Mitchell:
>>>> Yes, you've all heard it before [... blah blah blah ...]
>>>
>>> Can you please also give figures how much CPU time has been allotted 
>>> to dnetc in that respective situations?
>>>
>> I let the scheduler do the time allocation.  The result is that dnetc
>> gobbles whatever time remains available when higher priority processes
>> (i.e. every other process on the system) have nothing to do. With
>> SCHED_4BSD the resulting idle time is 0 (as reported by top).  I did
>> not take note of the idle time when I was doing the SCHED_ULE run.
>
> You are not answering my question.  I asked how much time did dnetc 
> use in the time where you were doing your test compile.
>
> The next question is then where you get the idea that a scheduler must 
> interpret 20 as "only if idle". Linux has scheduling classes with 
> "idle" and "best-effort" priority classes, for one.
>
> Yes, there are reports that FreeBSD is not responsive by default - but 
> this may make it get overall better throughput at the expense of 
> responsiveness, because it might be doing fewer context switches.  So 
> just complaining about a longer buildworld without seeing how much 
> dnetc did in the same wallclock time period is useless.  Periodic 
> rant's don't fix this lack of information.
>
>