kern.sched.quantum: Creepy, sadistic scheduler

[Peter]

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.

P.