Top wakeups causers

[Adam Jackson]

On Mon, 2007-05-14 at 12:11 -0400, Dave Jones wrote:
> On Mon, May 14, 2007 at 11:52:41AM -0400, Adam Jackson wrote:
>  > X uses setitimer() when it's actively servicing requests from clients.
>  > It schedules an alarm for ~20ms in the future so that it can know when a
>  > significant amount of time has elapsed, and therefore schedule other
>  > clients if they're ready.  So at worst, it'd wake up 50 times a second,
>  > but it'll only do so when it's already busy doing work.
> 
> Something that you pointed me at before was the -dumbsched option, which made it
> not wake up as often.   I'm sure you've explained to my sieve-like brain
> before, but what were the downsides of using this?
> If its not feasible to have this the default, would it make sense to have
> the xserver switch to it if the power source changes?

-dumbSched reverts to the (very) old dumb scheduler behaviour, which is
a trivial denial of service.  It basically doesn't check at all how long
each client is taking, so a single greedy client can trivially
monopolize the server.  You would rather not use it.

Remember, this alarm signal only gets sent to the server when the server
is already on the runqueue.  It's not a real wakeup, we're already in
C1.  (Someone, anyone, do the numbers here and show that I'm right.
Running the X server with -dumbSched shouldn't materially affect the
distribution of C-state time.)

The other option for accounting for client time would be to
gettimeofday() a lot more often, but that's really not acceptable.  It's
a very soft system call, but it's still more expensive than a plain
function call, heavy enough to slow down the common dispatch path by a
factor of 10.

The solution to this in other OSes has always been to allow the server
to claim to be executing in the CPU timeslice of some other process.
You don't preempt the server (as much) during those times, but you do
account that time to the client instead.  That way the kernel has enough
context to know which process to punish.  Although with multi-core
machines, the server still needs to account for that time too, since the
kernel isn't going to willingly leave CPUs idle.

- ajax