Messages in this thread | | | Date | Tue, 2 Nov 2004 14:52:20 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH] optional non-interactive mode for cpu scheduler |
| |
* Con Kolivas <kernel@kolivas.org> wrote:
> I'll look into coding it later this week (thanks for suggesting I do > it btw). This ordeal has left me seriously sleep deprived :P
:-|
> Since we're considering providing a special cpu policy for high > latency high cpu usage, does that mean we can now talk about other > policies like batch, isochronous etc? And in the medium to long term > future, gang and group?
SCHED_ISO would be interesting, but all SCHED_BATCH patches that i've seen so far were fundamentally broken. [ none protects against the possibility of a simple CPU hog starving a SCHED_BATCH task in kernel mode holding say /home's i_sem forever. None except the one i wrote a couple of years ago that is ;-) ]
but obviously any new scheduling policy first needs considerable testing, exposure and concensus. The main thing that makes SCHED_CPUBOUND possibly objectionable is that it could easily be used as a flag to 'turn off the interactivity code', which is wrong and just prolongs the fixing of interactivity-estimator bugs. Scientific apps burn CPU time exclusively and they have a stable priority at the low end of the range.
One exception would be CPU-bound code with multiple threads which interact with each other - one always runs but the others always sleep. A possible solution would be to exclude all inter-task synchronization methods from the 'interactivity boost' and only hard-device-waits would be considered true 'waiting', such as keyboard, mouse, disk or network IO.
Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |