[PATCH] smartsched: Tweak the default scheduler intervals

[Adam Jackson]

On Tue, 1985-11-05 at 17:07 +0100, Mark Kettenis wrote:
> > From: Adam Jackson <ajax at redhat.com>
> > Date: Tue,  5 Nov 2013 10:41:32 -0500
> > 
> > A default timeslice of 20ms means a pathological client can ruin up to
> > two frames per scheduler tick.  And a fifth of a second is just insane.
> > 
> > Pick two different numbers out of the hat.  A 5ms slice means you can
> > probably keep up with two or three abusive clients, and letting it burst
> > to 15ms should give you about all the timeslice you need for a
> > fullscreen game (that's doing server-side rendering for some reason).
> > I suspect this is about as good as we can do without actually going
> > preemptive, which is an entire other nightmare.
> 
> What would the consequence of these new timings be on a kernel that
> has a "traditional" 10ms timeslice?  I have a suspicion that the new
> timings would effectively disable the effects of "smart" scheduling...

I was going to assume the 10ms timeslice is merely the unix scheduler's
preemption interval, and not the minimum granularity for setitimer
alarms.  But then I read BSD's setitimer man page, and was suddenly very
happy I run something else.  (Honestly, you're on the runqueue, you know
how to set timers more finely than 100Hz and you already expect to be
awake for the next 10ms, maybe do the trivial amount of integer math
required to kick the timer interrupt both when the user asked for it and
on the next scheduler tick.)

Anyway.  Effectively that would mean the default timeslice would be the
system timer granularity, and the maximum timeslice would be (15/5) = 3
times as long as that; we don't actually inspect the wall time in the
scheduler, we just use the alarm to compute ticks.  So, 10ms tick and
30ms max slice.  So this is still an improvement even there, since now
you'd be able to get around to at least two clients per frame of video
(assuming the X server is perfectly scheduled, which the 10ms kernel
tick means it probably won't be, but yafiygi I guess).

The current 20ms tick means a greedy client can monopolize _two_ X
server kernel ticks; if you have that plus one other process at 100%CPU
then getting out of the greedy client can be 40ms of wall time.  That's
2.4 frame intervals, so you'd be hitting somewhere between 20 and 30
fps.  Not something I'd inflict on myself.

If my assumption from the first paragraph was true then you would end up
with the expected 5ms client tick and 15ms maximum client slice, and the
kernel's preemption interval would only affect how often the server
actually gets scheduled.

- ajax