Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

From: David Lang
Date: Tue Mar 13 2007 - 02:24:05 EST


On Mon, 12 Mar 2007, Lee Revell wrote:

On 3/12/07, David Lang <david.lang@xxxxxxxxxxxxxxxxxx> wrote:
the problem comes when this isn't enough. if you have several CPU hogs on a
system, and they are all around the same priority level, how can the scheduler
know which one needs the CPU the most for good interactivity?

in some cases you may be able to directly detect that your high-priority process
is waiting for another one (tracing pipes and local sockets for example), but
what if you are waiting for several of them? (think a multimedia desktop waiting
for the sound card, CDRom, hard drive, and video all at once) which one needs
the extra CPU the most?

I'm not an expert in this area by any means but after reading this
thread the OSX solution of simply telling the kernel "I'm the GUI,
schedule me accordingly" looks increasingly attractive. Why make the
kernel guess when we can just be explicit?

this can solve the specific problem (and since 'nice' is the natural way to tell the kernel this, it's not even a one-shot solution).

however Linus is right, the real underlying problem is where the user is waiting on a server. if this issue could be solved then a lot of things would benifit.

Con, as a quick hack (probably a bad idea as I'm not a scheduling expert), if a program blocks on another program (via a pipe or socket) could you easily give the rest of the first program's timeslice to the second one, without makeing it loose it's own?

I'm thinking that doing the dumb thing and just throwing a bit more CPU at the thing you are waiting for may work. (assuming that the server process actually does something useful with the extra CPU time it gets)

as far as latencies go, it would be like turning every process on the system into a cpu hog.

David Lang

Does anyone know of a UNIX-like system that has managed to solve this
problem without hooking the GUI into the scheduler?

Lee

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/