public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ivan Schreter <is@zapwerk.com>
To: linux-kernel@vger.kernel.org
Cc: george anzinger <george@mvista.com>
Subject: Re: [patch] sched_yield in 2.2.x
Date: Wed, 30 May 2001 11:07:00 +0200	[thread overview]
Message-ID: <01053011323600.01230@linux> (raw)
In-Reply-To: <01053002030500.01197@linux> <3B146125.77845217@mvista.com>
In-Reply-To: <3B146125.77845217@mvista.com>

Hello,

I'm not subscribed, so replies please CC: to me.

[...]

> > (I changed it to -1 just to be sure this process isn't accidentally
> > picked when there is other process to run - maybe I'm wrong here, but
> > 2.4.5 gives it also goodness -1, so it should be OK).
[...]
> The -1 is better than 0 since 0 will trigger a recalc if no other tasks
> have any time left.  (Or do you want this to happen?  As you have it,
> the yielding task will get control if all other tasks in the run list
> have zero counters.  Seems like the recalculation should happen to find
> a better candidate.)

Yes, I think that is OK according to specs. If we get a recalc, then we get
control anyway, since we have some time left when calling sched_yield(). Or am
I wrong here? Anyway, it performs quite well in tests...

> The real problem with this patch is that if a real time task yields, the
> patch will cause the scheduler to pick a lower priority task or a
> SCHED_OTHER task.  This one is not so easy to solve.  You want to scan
> the run_list in the proper order so that the real time task will be the
> last pick at its priority.  Problem is, the pre load with the prev task
> is out of order.  You might try: http://rtsched.sourceforge.net/

Well, let's look at it this way: real-time tasks may want to yield when they
are waiting for something to happen that is not system-controlled (like a
user-mode spinlock). Otherwise they would be waiting in (un)interruptible sleep
controlled by the kernel. So when a RR task yields, then it yields because some
condition isn't met. So it has to wait anyway. Scheduling a lower
priority task in the meantime will do only good to the system IMHO.

I know this is not quite standard, but to make it work standards-compliant
(task will continue to run if there are no other tasks blabla) it is enough to
check # of runnable tasks in the run queue in sys_sched_yield() and return
immediately if we are the only task running. I can implement that. Anybody
thinks it's worth it?

Ivan Schreter
is@zapwerk.com

  reply	other threads:[~2001-05-30  9:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-29 23:49 [patch] sched_yield in 2.2.x Ivan Schreter
2001-05-30  2:55 ` george anzinger
2001-05-30  9:07   ` Ivan Schreter [this message]
2001-05-30 10:54   ` [patch] sched_yield in 2.2.x - version 2 Ivan Schreter

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=01053011323600.01230@linux \
    --to=is@zapwerk.com \
    --cc=george@mvista.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox