kern.sched.quantum: Creepy, sadistic scheduler
pmc at citylink.dinoex.sub.org
Wed Apr 18 18:13:20 UTC 2018
Hi all of You,
thank You very much for Your commenting and reports!
From what I see, we have (at least) two rather different demands here:
while George looks at the over-all speed of compute throughput, others
are concerned about interactive response.
My own issue is again a little bit different: I am running this small
single-CPU machine as my home-office router, and it also runs a backup
service, which involves compressing big files and handling an outgrown
database (but that does not need to happen fast, as it's just backup stuff).
So, my demand is to maintain a good balance between realtime network
activity being immediately served, and low-priority batch compute jobs,
while still staying responsive to shell-commands - but the over-all
compute throughput is not important here.
But then, I find it very difficult to devise some metrics, by which such
a demand could be properly measured, to get compareable figures.
George Mitchell wrote:
> I suspect my case (make buildworld while running misc/dnetc) doesn't
> qualify. However, I just completed a SCHED_ULE run with
> preempt_thresh set to 5, and "time make buildworld" reports:
> 7336.748u 677.085s 9:25:19.86 23.6% 27482+473k 42147+431581io 38010pf+0w
> Much closer to SCHED_4BSD! I'll try preempt_thresh=0 next, and I
> guess I'll at least try preempt_thresh=224 to see how that works
> for me. -- George
I found that preempt_thresh=0 cannot be used in practice:
When I try to do this on my quadcode desktop, and then start four
endless-loops to get the cores busy, the (internet)radio will have a
dropout every 2-3 seconds (and there is nothing else running, just a
sleeping icewm and a mostly sleeping firefox)!
So, the (SMP) system *depends* on preemption, it cannot handle streaming
data without it. (@George: Your buildworld test is pure batch load, and
may not be bothered by this effect.)
I think the problem is *not* to be solved by finding a good setting for
preempt_thresh (or other tuneables). I think the problem lies deeper,
and these tuneables only change its appearance.
I have worked out a writeup explaining my thoughts in detail, and I
would be glad if You stay tuned and evaluate that.
More information about the freebsd-stable