Messages in this thread | | | Date | Sun, 01 Aug 1999 19:21:13 +0200 | From | Artur Skawina <> | Subject | Re: Results from Artur Skawini's SCHED_IDLE patch |
| |
cd_smith@ou.edu wrote: > > variations fit well within the variation I got running lmbench multiple > times on the same kernel. Bonnie performance dropped considerably, > though, when lmbench was running in the background. This is most likely > because compared to lmbench, bonnie tends to use a lot less CPU time. So > lmbench had a chance to get in there and pollute cache for the bonnie > task. This is an expected result, and the only way to fix it reasonably > is to not run idle tasks.
SCHED_IDLE is not meant to (and cannot) be used as an administrative restriction. It is only a way to tell the system "this process isn't essential, don't run this unless you have some cputime to waste". Ie the fact that the process can trick the system into scheduling it like a normal process is uninteresting. It could just set its scheduling policy to SCHED_OTHER if it wanted (you could prevent that, but allowing a normal user to un-idle his own process is a _feature_). IOW SCHED_IDLE is for cpu-bound processes (like raytracers, numeric computations, compression etc); an io-bound process is not a good candidate for SCHED_IDLE (you would have to also somehow restrict the io-bw it can use, as that could have worse effects on the system than the few % of cputime). I'll look into the bonnie #s; but were I to guess it's lmbench doing a _lot_ of syscalls - the patch i posted didn't penalize the idle process for doing that (even though both the original (unpublished) patch, and my current one does - i removed this, and later added it back). I'll see if it still is a problem, and if yes will try to find a reasonable compromise [==penalty :)]. Thanks for the numbers (these were for UP, right?).
- 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/
| |