On Sun, Feb 27, 2000 at 01:19:26AM +0000, Nix wrote:
> Sorry, but this argument is fallacious. Sure, a SCHED_IDLE process
> can grab some userspace semaphore and then never get any time
> slices. However, it can also grab some userspace semaphore and then
> never release it, even now --- and the same effect results. It can
> also be SIGSTOPped, which does the same thing again (and also
> doesn't affect stuff in kernel space, for obvious reasons).
So my introducing SCHED_IDLE we add another case where users can
break their code in seemly strange ways?
I'm not saying this is a bad thing, but I don't see how it is a good
thing either.
> I agree that a process in kernel space must always be
> non-SCHED_IDLE, or perhaps that SCHED_IDLE is treated as
> SCHED_OTHER as long as a process is in kernel mode. But banning it
> in userspace because of userspace locks is wrong. (Consider that
> most processes that are likely to be SCHED_IDLE will spend nearly
> all their time in userspace, so banning kernel-space SCHED_IDLE
> will have negligible effect on the performance improvement achieved
> by this code.)
I still not convinced -- what problem does SCHED_IDLE solve? Why
can't we just extended the range of acceptable process priorities as
other OSs (eg. Solaris) have done?
Sure -- its not quite the same thing, but in reality is the 1% or so
different you might see with rc5crack or whatever going to really
matter all that much?
-cw
-
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/
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:16 EST