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 <[email protected]>
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
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?
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 ...
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
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
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 <[email protected]>
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
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 <[email protected]>
(the armchair engineer)
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
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
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