Re: Scheduling of low-priority background processes

[Kevin Easton <s3159795@student.anu.edu.au>]

> > 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