Re: Schedule idle
Greg Mildenhall (greg@networx.net.au)
Wed, 11 Nov 1998 20:07:11 +0800 (WST)
On Tue, 10 Nov 1998 yodaiken@chelm.cs.nmt.edu wrote:
> > backround jobs like rc5 _shall_not_ steal 30% cpu time from real important
> > computation batch jobs but should only run when the system really is _idle_
> > otherwise. even nice-10 vs. nice-19 isnt' decoupled enough:
> Decoupled enough for what? If you want RC5 jobs to not even use this tiny
> amount of cpu while the batch jobs are running, why not:
>
> start batch_job
> signal rc5 process to shut down
> if( !fork())
> exec batch job
> else wait()
> restart rc5
Because the two might be run by completely different users.
The user who started the RC5 clearly doesn't want it to be scheduled while
the other user's batch is running, but the RC5 user has no method within
the standard scheduling model by which he can ensure this - he can only
limit the time, and because of IO competition (worst case might be
swapping), even a small percentage of runtime can have devestating
effects on the performance of the batch.
Just like at the RT end, there are things that cannot be done within the
simple "niceness" model. And once you step outside of that model, you lose
a whole lot of assumptions you have made, and have to work at keeping
things safe and keeping things adherent to desired priorities.
This is well-accepted at the high-end, where assumptions are generally
made about the behaviour of the RT process.
The thing that sets sched-idle apart is that it is something we really
want to offer to normal users. RT, (hard or soft) can only really be
offered to privledged users, and as such, we can assume to a certain
extent that they will use it properly.
To have a sched-idle that solves the problem above (the RC5 one) requires
us to step outside of the standard model, and then make sure that the
assumptions based on the standard model still hold.
It's not an easy problem, but it is certainly soluble - the questions are
about where the tradeoffs become too much. (IMHO, of course.)
-Greg Mildenhall
-
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/