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 : [EMAIL PROTECTED]
To : "Giovanni Tusa" [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
> 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
-
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/
