> As for SCHED_IDLE, unless I've totally missed the point, it's an example
> of trying to solve a sys admin problem by breaking the kernel.
> How about a cron script that uses nice to make sure that no task is ever
> as low priority as the RC5 ?
at least for me this won't help, because for all those normal UNIX schedulers
(those which I've seen) even nice-0 and nice-19 jobs compete too much
(IMHO 5% for nice-19 while nice-0 is running is still a bit _too_much_).
if using a cron script, it would have to SIGSTOP the `idle task'
and SIGCONT it later. this was the way to go until I got SCHED_IDLE...
so far SCHED_IDLE was fine (but not perfect) for it's job, but I see that
it has bad side effects which have to be fixed. but how to achieve this
while not giving up the real request ?
one idea was just to add another 20 nice levels and nice-39 vs. nice-19
should be the same competition ratio as nice-19 vs. nice-0.
this would give enough scale for the three `execution clases' for
interactive, long important coompuatation batchs, and idle fun projects.
but then nice-39 vs. nice-0 would be ~0.25% and you still have some sort
of DoS, because nice-39 jobs can lock resources for a _long_ time
(no longer forever, but for too long...).
Harald
--
All SCSI disks will from now on ___ _____
be required to send an email notice 0--,| /OOOOOOO\
24 hours prior to complete hardware failure! <_/ / /OOOOOOOOOOO\
\ \/OOOOOOOOOOOOOOO\
\ OOOOOOOOOOOOOOOOO|//
Harald Koenig, \/\/\/\/\/\/\/\/\/
Inst.f.Theoret.Astrophysik // / \\ \
koenig@tat.physik.uni-tuebingen.de ^^^^^ ^^^^^
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/