sched_yield behavior

sched_yield behavior

[Giovanni Tusa]

Hi all,
I have a question about the sched_yield behavior of Linux O(1) scheduler,
for RT tasks.
By reading some documentation, I found that " ....real-time tasks are a
special case, because
when they want to explicitly yield the processor to other waiting processes,
they are merely
moved to the end of their priority list (and not inserted into the expired
array, like conventional
processes)."
I have to implement an RT task with the highest priority in the system (it
is also the only task within the
priority list for such priority level). Moreover, it has to be a SCHED_FIFO
task,  so that it can preempt
SCHED_RR ones, because of its strong real-time requirements. However,
sometimes it should relinquish the
CPU, to give to other tasks a chance to run.
Now, what happen if it gives up the CPU by means of the sched_yield() system
call?
If  I am not wrong, the scheduler will choose it again (it will be still the
higher priority task, and the only of its priority list).
I have to add an explicit sleep to effectively relinquish the CPU for some
time, or the scheduler can deal with such a
situation in another way?

Any advice will be appreciated.
Giovanni

Re: sched_yield behavior

[Lee Revell]

On Sun, 2005-02-27 at 11:58 +0100, Giovanni Tusa wrote:
> Hi all,
> I have a question about the sched_yield behavior of Linux O(1) scheduler,
> for RT tasks.
> By reading some documentation, I found that " ....real-time tasks are a
> special case, because
> when they want to explicitly yield the processor to other waiting processes,
> they are merely
> moved to the end of their priority list (and not inserted into the expired
> array, like conventional
> processes)."
> I have to implement an RT task with the highest priority in the system (it
> is also the only task within the
> priority list for such priority level). Moreover, it has to be a SCHED_FIFO
> task,  so that it can preempt
> SCHED_RR ones, because of its strong real-time requirements. However,
> sometimes it should relinquish the
> CPU, to give to other tasks a chance to run.
> Now, what happen if it gives up the CPU by means of the sched_yield() system
> call?
> If  I am not wrong, the scheduler will choose it again (it will be still the
> higher priority task, and the only of its priority list).
> I have to add an explicit sleep to effectively relinquish the CPU for some
> time, or the scheduler can deal with such a
> situation in another way?

What exactly are you trying to do?  I don't understand how the task
could have "strong real-time requirements" if it's CPU bound.  What is
the exact nature of the real time constraint?

Lee

Re: sched_yield behavior

[Nick Piggin]

Giovanni Tusa wrote:

> If  I am not wrong, the scheduler will choose it again (it will be still the
> higher priority task, and the only of its priority list).
> I have to add an explicit sleep to effectively relinquish the CPU for some
> time, or the scheduler can deal with such a
> situation in another way?

Yes, the scheduler will choose it again. This behaviour is also
specified in the relevant standards.

Your alternatives may be to use other methods of userspace
synchronisation (eg. pipes, semaphores), or to use timers.

Re: sched_yield behavior

[gtusa]

First of all, thanks to all for the helpful replies.
I have simplified my example, because I was only interested in understanding if there was particular behavior performed by the new scheduler after a sched_yield() call. 
Anyway, I try to explain better my requirements. I have to implement a task which splits its job into two different blocks: the first concerns operations which must be performed within a limited time interval, so a very fast response is required; the second one concerns operations which can be a little delayed without problems. For some other reasons, the two blocks cannot be implemented in two different tasks. Therefore, because of the presence of the real-time block, an high real-time priority must be assigned to the whole task. On the other hand, if it uses the resources for a long time interval, it should sched_yield on behalf of other tasks (of course only after the real-time block operations have been completed).  

Giovanni
    
---------- Initial Header -----------

>From      : linux-kernel-owner@vger.kernel.org
To          : "Giovanni Tusa" gtusa@inwind.it
Cc          : linux-kernel@vger.kernel.org
Date      : Sun, 27 Feb 2005 12:02:13 -0500
Subject : Re: sched_yield behavior

> On Sun, 2005-02-27 at 11:58 +0100, Giovanni Tusa wrote:
> > Hi all,
> > I have a question about the sched_yield behavior of Linux O(1) scheduler,
> > for RT tasks.
> > By reading some documentation, I found that " ....real-time tasks are a
> > special case, because
> > when they want to explicitly yield the processor to other waiting processes,
> > they are merely
> > moved to the end of their priority list (and not inserted into the expired
> > array, like conventional
> > processes)."
> > I have to implement an RT task with the highest priority in the system (it
> > is also the only task within the
> > priority list for such priority level). Moreover, it has to be a SCHED_FIFO
> > task,  so that it can preempt
> > SCHED_RR ones, because of its strong real-time requirements. However,
> > sometimes it should relinquish the
> > CPU, to give to other tasks a chance to run.
> > Now, what happen if it gives up the CPU by means of the sched_yield() system
> > call?
> > If  I am not wrong, the scheduler will choose it again (it will be still the
> > higher priority task, and the only of its priority list).
> > I have to add an explicit sleep to effectively relinquish the CPU for some
> > time, or the scheduler can deal with such a
> > situation in another way?
> 
> What exactly are you trying to do?  I don't understand how the task
> could have "strong real-time requirements" if it's CPU bound.  What is
> the exact nature of the real time constraint?
> 
> Lee
> 
> -
> 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/
> 



____________________________________________________________
6X velocizzare la tua navigazione a 56k? 6X Web Accelerator di Libero!
Scaricalo su INTERNET GRATIS 6X http://www.libero.it