Scheduler priorities

Scheduler priorities

[Nuno Miguel Rodrigues]

Hi,

Does Linux support a fixed process scheduling priority, in the 2.4.x
releases?
If not, are there any plans to support it?

Thanks.


-- 
Nuno M. Rodrigues <nmr@co.sapo.pt>
Systems Administrator
SAPO - Servico de Apontadores Portugueses
http://www.sapo.pt/
"Logic is a systematic method of coming to the wrong conclusion with confidence." -Edward A. Murphy

Re: Scheduler priorities

[Mike Fedyk]

On Tue, Mar 26, 2002 at 11:41:39AM +0000, Nuno Miguel Rodrigues wrote:
> 
> Hi,
> 
> Does Linux support a fixed process scheduling priority, in the 2.4.x
> releases?
> If not, are there any plans to support it?

Can you elaborate?  What do you mean by "fixed process"?  Minimum percentage
of CPU?

Re: Scheduler priorities

[Frank Schaefer]

On Tue, 2002-03-26 at 18:55, Mike Fedyk wrote:
> On Tue, Mar 26, 2002 at 11:41:39AM +0000, Nuno Miguel Rodrigues wrote:
> > 
> > Hi,
> > 
> > Does Linux support a fixed process scheduling priority, in the 2.4.x
> > releases?
> > If not, are there any plans to support it?
> 
> Can you elaborate?  What do you mean by "fixed process"?  Minimum percentage
> of CPU?
Hi,

I'd read this ...
a fixed prority of some process ...

Re: Scheduler priorities

[Nuno Miguel Rodrigues]

On 27 Mar 2002, Frank Schaefer wrote:

> On Tue, 2002-03-26 at 18:55, Mike Fedyk wrote:
> > On Tue, Mar 26, 2002 at 11:41:39AM +0000, Nuno Miguel Rodrigues wrote:
> > >
> > > Hi,
> > >
> > > Does Linux support a fixed process scheduling priority, in the 2.4.x
> > > releases?
> > > If not, are there any plans to support it?
> >
> > Can you elaborate?  What do you mean by "fixed process"?  Minimum percentage
> > of CPU?
> Hi,
>
> I'd read this ...
> a fixed prority of some process ...

Indeed.  In other words a priority that is not dynamically adjusted over
time.  Like a real-time scheduling priority.

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

Re: Scheduler priorities

[Robert Love]

On Wed, 2002-03-27 at 08:06, Nuno Miguel Rodrigues wrote:

> Indeed.  In other words a priority that is not dynamically adjusted over
> time.  Like a real-time scheduling priority.

Yes, Linux has two - SCHED_FIFO and SCHED_RR.

	Robert Love

Re: Scheduler priorities

[Wessel Dankers]

On 2002-03-27 08:41:51-0500, Robert Love wrote:
> On Wed, 2002-03-27 at 08:06, Nuno Miguel Rodrigues wrote:
> 
> > Indeed.  In other words a priority that is not dynamically adjusted over
> > time.  Like a real-time scheduling priority.
> 
> Yes, Linux has two - SCHED_FIFO and SCHED_RR.

Any plans for a SCHED_IDLE?

--
Wessel Dankers <wsl@fruit.eu.org>

Re: Scheduler priorities

[Robert Love]

On Wed, 2002-03-27 at 15:23, Wessel Dankers wrote:

> Any plans for a SCHED_IDLE?

I think Ingo Molnar has mentioned lately doing one.

The problem is, it is not easy to implement right - there are priority
inversion issues to deal with ...

	Robert Love

Re: Scheduler priorities

[Wessel Dankers]

On 2002-03-27 16:14:55-0500, Robert Love wrote:
> On Wed, 2002-03-27 at 15:23, Wessel Dankers wrote:
> 
> > Any plans for a SCHED_IDLE?
> 
> I think Ingo Molnar has mentioned lately doing one.
> 
> The problem is, it is not easy to implement right - there are priority
> inversion issues to deal with ...

Well evidently it should be root-only, just like SCHED_RR and SCHED_FIFO.
If the priority inversion issues are worked out this restriction could be
removed. I remember discussing this problem with Rik van Riel.
The kernel-preempt patch seems to be able to detect when a process holds a
lock; perhaps the process scheduler can temporarily revert to SCHED_NORMAL
when this is the case? Preferably with a large nice value.

--
Wessel Dankers <wsl@fruit.eu.org>

(the armchair engineer)

Re: Scheduler priorities

[Robert Love]

On Thu, 2002-03-28 at 02:08, Wessel Dankers wrote:

> Well evidently it should be root-only, just like SCHED_RR and SCHED_FIFO.
> If the priority inversion issues are worked out this restriction could be
> removed. I remember discussing this problem with Rik van Riel.
> The kernel-preempt patch seems to be able to detect when a process holds a
> lock; perhaps the process scheduler can temporarily revert to SCHED_NORMAL
> when this is the case? Preferably with a large nice value.

The preempt-kernel patch does keep track of the lock count, but it does
not include semaphores and those are what we need to worry about.

I also don't think it is enough that SCHED_IDLE only be settable by
root.  Regardless of what permissions it takes to set the scheduling
class, a "SCHED_IDLE" task should never be capable of harming an RT
task.

One solution I have come across is checking whether the task is
returning to kernel or user mode and acting appropriately.  As needed,
the task can be scheduled as SCHED_NORMAL.  This situation could even be
special-cased like ptrace and not impact normal scheduling.  Perhaps
this is what Ingo had in mind ... I hope he is still interested and
presents some code.

I know all this because I tried to implement SCHED_IDLE about a year
ago.  There were arguments against every approach, and SCHED_IDLE will
never be accepted until they are all satisfied.  If we want it, it needs
to be done right.

	Robert Love

Re: Scheduler priorities

[Pavel Machek]

Hi!

> > Well evidently it should be root-only, just like SCHED_RR and SCHED_FIFO.
> > If the priority inversion issues are worked out this restriction could be
> > removed. I remember discussing this problem with Rik van Riel.
> > The kernel-preempt patch seems to be able to detect when a process holds a
> > lock; perhaps the process scheduler can temporarily revert to SCHED_NORMAL
> > when this is the case? Preferably with a large nice value.
> 
> The preempt-kernel patch does keep track of the lock count, but it does
> not include semaphores and those are what we need to worry about.
> 
> I also don't think it is enough that SCHED_IDLE only be settable by
> root.  Regardless of what permissions it takes to set the scheduling
> class, a "SCHED_IDLE" task should never be capable of harming an RT
> task.

On each entry of kernel, promote SCHED_IDLE task to SCHED_NORMAL, and
demote it at exit. This can be done with 0 overhad on hot paths.


> One solution I have come across is checking whether the task is
> returning to kernel or user mode and acting appropriately.  As needed,
> the task can be scheduled as SCHED_NORMAL.  This situation could even be
> special-cased like ptrace and not impact normal scheduling.  Perhaps
> this is what Ingo had in mind ... I hope he is still interested and
> presents some code.
> 
> I know all this because I tried to implement SCHED_IDLE about a year
> ago.  There were arguments against every approach, and SCHED_IDLE will
> never be accepted until they are all satisfied.  If we want it, it needs
> to be done right.

What's the problem with "promote at enter" approach? Using ptrace
trick, it can be 0 overhead. [Was that your code that cleverly used
ptrace?] What is problem with it?
									Pavel

-- 
(about SSSCA) "I don't say this lightly.  However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa

Re: Scheduler priorities

[Robert Love]

On Fri, 2002-03-29 at 16:42, Pavel Machek wrote:

> On each entry of kernel, promote SCHED_IDLE task to SCHED_NORMAL, and
> demote it at exit. This can be done with 0 overhad on hot paths.

Agreed.

> What's the problem with "promote at enter" approach? Using ptrace
> trick, it can be 0 overhead. [Was that your code that cleverly used
> ptrace?] What is problem with it?

There is no problem with the ptrace approach, it is good - I have
experimented with that solution myself.  There is just a lot more to
SCHED_IDLE than "make the task only run when nothing else wants to" and
even the ptrace solution may involve a bit of work.

	Robert Love