> > On those systems, you could assign a scheduling priority lower than
> > the one nomally used by interactive processes to CPU-hogging,
> > numbercrunching tasks. These tasks would then use up any CPU time left
> > over by interactive processes without otherwise interfering with them.
> > I always found this feature very useful (think of SETI@home!).
>
>
> > But that idea is so obvious, and since nobody did it so far, I am
> > probably missing something. What is it?
>
>
> Priority inversion. I did a patch which does exactly
> what you describe, around the 2.1 timeframe. It worked
> fine most of the time, but occasionally the following
> happened:
>
>
> 1) a SCHED_IDLE process got hold of some kernel lock
> 2) a normal, low-priority process started eating CPU
> for a number of seconds
> 3) a high-priority normal process wanted the lock the
> SCHED_IDLE task had, but had to wait several seconds,
> at times up to a minute, before the SCHED_IDLE task
> got a chance to run and release the lock
>
>
> This wasn't too much of a problem on my own system, but
> of course this is an easily exploitable vulnerability for
> attackers.
>
>
> For me, this just means we should improve the scheduler so
> nice levels are stronger ... say that a nice +20 process
> only gets 1% of the CPU of a normal priority process ;)
>
What if the SCHED_IDLE behaviour only applies when the process
is in userspace? Couldn't scheduler compare the process's
instruction pointer against the kernel/user break point, and
if the process is in the kernel, then just treat it like a
normal process?
>
> regards,
>
>
> Rik
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Nov 07 2001 - 21:00:29 EST