[lkml]   [2004]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] optional non-interactive mode for cpu scheduler

* Con Kolivas <> 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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:07    [W:0.085 / U:1.720 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site