On Mon, 12 Mar 2007, Lee Revell wrote: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 -
| Andrew Morton | -mm merge plans for 2.6.23 |
| Rafael J. Wysocki | [Bug #11207] VolanoMark regression with 2.6.27-rc1 |
| Zhang, Yanmin | AIM7 40% regression with 2.6.26-rc1 |
| Con Kolivas | [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2 |
git: | |
| Gregory Haskins | [RFC PATCH 03/17] vbus: add connection-client helper infrastructure |
| David Woodhouse | [PATCH 03/30] solos: FPGA and firmware update support. |
| Natalie Protasevich | [BUG] New Kernel Bugs |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
