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
next prev parent 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 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.