Re: [PATCH] optional non-interactive mode for cpu scheduler

[Ingo Molnar]

* Con Kolivas <kernel@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/