Re: sched_yield behavior
gtusa_at_inwind.it
Date: 03/01/05
- Previous message: Russell King: "Re: updating mtime for char/block devices?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 1 Mar 2005 12:15:08 +0100 To: "rlrevell" <rlrevell@joe-job.com>
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
-
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/
- Previous message: Russell King: "Re: updating mtime for char/block devices?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
