Chris Wedgwood <cw@f00f.org> writes:
> On Sat, Feb 26, 2000 at 11:30:15AM +0100, Manfred Spraul wrote:
>
> > What about using SCHED_IDLE only for processes that are in user
> > space? e.g. ret_with_reschedule calls a special
> > "schedule_with_SCHED_IDLE()". As soon as a thread runs within
> > kernel space, we ignore SCHED_IDLE.
>
> This would only fix kernel-space deadlocks -- think about pthreads
> and NSPR when you have userspace locking.
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).
We can safely assume that kernel space will not do that, but we cannot
assume that userspace won't.
The only difference is that now users can trigger this effect, as well
as program bugs.
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.)
(IMHO, of course. ICBW.)
--
`> KNOWLEDGE AND SKILLS
You must have some, but I don't see any evidence of it.'
--- Craig Hardie flames a luser recruitment consultant
advertising `Microsoft based solutions' on uk.comp.os.linux
-
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