All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lee Revell <rlrevell@joe-job.com>
To: Giovanni Tusa <gtusa@inwind.it>
Cc: linux-kernel@vger.kernel.org
Subject: Re: sched_yield behavior
Date: Sun, 27 Feb 2005 12:02:13 -0500	[thread overview]
Message-ID: <1109523733.30866.2.camel@krustophenia.net> (raw)
In-Reply-To: <00e901c51cbb$45b3cac0$65071897@gtusa>

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


  reply	other threads:[~2005-02-27 17:02 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-27 10:58 sched_yield behavior Giovanni Tusa
2005-02-27 17:02 ` Lee Revell [this message]
2005-02-27 22:04 ` Nick Piggin
  -- strict thread matches above, loose matches on Subject: below --
2005-03-01 11:15 gtusa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1109523733.30866.2.camel@krustophenia.net \
    --to=rlrevell@joe-job.com \
    --cc=gtusa@inwind.it \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.