From: "David Schwartz" <davids@webmaster.com>
To: "Matt Mackall" <mpm@selenic.com>
Cc: "linux-kernel" <linux-kernel@vger.kernel.org>, <ck@vds.kolivas.org>
Subject: RE: RSDL-mm 0.28
Date: Mon, 12 Mar 2007 06:22:39 -0700 [thread overview]
Message-ID: <MDEHLPKNGKAHNMBLJOLKAEBACDAC.davids@webmaster.com> (raw)
In-Reply-To: <8cd998d50703101828l71fbec7bi9a819ad7b7fd9828@mail.gmail.com>
> > There's a substantial performance hit for not yield, so we probably
> > want to investigate alternate semantics for it. It seems reasonable
> > for apps to say "let me not hog the CPU" without completely expiring
> > them. Imagine you're in the front of the line (aka queue) and you
> > spend a moment fumbling for your wallet. The polite thing to do is to
> > let the next guy in front. But with the current sched_yield, you go
> > all the way to the back of the line.
> Well... are you advocating we change sched_yield semantics to a
> gentler form? This is a cinch to implement but I know how Ingo feels
> about this. It will only encourage more lax coding using sched_yield
> instead of proper blocking (see huge arguments with the ldap people on
> this one who insist it's impossible not to use yield).
The basic point of sched_yield is to allow every other process at the same
static priority level a chance to use the CPU before you get it back. It is
generally an error to use sched_yield to be nice. It's nice to get your work
done when the scheduler gives you the CPU, that's why it gave it to you.
It is proper to use sched_yield as an optimization when it more efficient to
allow another process/thread to run than you, for example, when you
encounter a task you cannot do efficiently at that time because another
thread holds a lock.
It's also useful prior to doing something that can most efficiently be done
without interruption. So a thread that returns from 'sched_yield' should
ideally be given a full timeslice if possible. This may not be sensible if
the 'sched_yield' didn't actuall yield, but then again, if nothing else
wants to run, why not give the only task that does a full slice?
In no case is much of anything guaranteed, of course. (What can you do if
there's no other process to yield to?)
Note that processes that call sched_yield should be rewarded for doing so
just as process that block on I/O are, assuming they do in fact wind up
giving up the CPU when they would otherwise have had it.
DS
next prev parent reply other threads:[~2007-03-12 13:22 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-11 1:35 Matt Mackall
2007-03-11 2:28 ` Con Kolivas
2007-03-11 3:16 ` Andrew Morton
2007-03-11 3:43 ` William Lee Irwin III
2007-03-11 3:59 ` Con Kolivas
2007-03-11 3:39 ` Andrew Morton
2007-03-11 3:44 ` Con Kolivas
2007-03-11 4:01 ` Matt Mackall
2007-03-11 4:03 ` Matt Mackall
2007-03-11 6:19 ` Con Kolivas
2007-03-12 5:38 ` RSDL for 2.6.21-rc3- 0.29 Gene Heskett
2007-03-12 5:48 ` Con Kolivas
2007-03-12 6:37 ` Gene Heskett
2007-03-12 10:04 ` Gene Heskett
2007-03-12 12:51 ` Douglas McNaught
2007-03-12 18:28 ` Gene Heskett
2007-03-12 18:46 ` Douglas McNaught
2007-03-12 19:10 ` Gene Heskett
2007-03-12 19:14 ` Lee Revell
2007-03-12 19:43 ` Douglas McNaught
2007-03-12 19:54 ` Patrick Mau
2007-03-12 20:24 ` Gene Heskett
2007-03-13 1:32 ` Stracing Amanda (was: RSDL for 2.6.21-rc3- 0.29) Douglas McNaught
2007-03-13 2:39 ` Gene Heskett
2007-03-13 3:01 ` Nish Aravamudan
2007-03-13 4:04 ` Gene Heskett
2007-03-13 4:45 ` Willy Tarreau
2007-03-13 5:48 ` Gene Heskett
2007-03-12 13:22 ` David Schwartz [this message]
2007-03-12 14:54 ` RSDL-mm 0.28 Ray Lee
2007-03-13 7:22 ` Nick Piggin
2007-03-11 7:32 ` Willy Tarreau
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=MDEHLPKNGKAHNMBLJOLKAEBACDAC.davids@webmaster.com \
--to=davids@webmaster.com \
--cc=ck@vds.kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mpm@selenic.com \
/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
all inboxes | Powered by JetHome®