From: David Schwartz <davids@webmaster.com>
To: <mgix@mgix.com>, <root@chaos.analogic.com>,
Chris Friesen <cfriesen@nortelnetworks.com>
Cc: <rml@tech9.net>, <linux-kernel@vger.kernel.org>
Subject: RE: Question about sched_yield()
Date: Tue, 18 Jun 2002 12:11:12 -0700 [thread overview]
Message-ID: <20020618191114.AAA27826@shell.webmaster.com@whenever> (raw)
In-Reply-To: <AMEKICHCJFIFEDIBLGOBCEEICBAA.mgix@mgix.com>
On Tue, 18 Jun 2002 11:05:36 -0700, mgix@mgix.com wrote:
>> Your assumptions are just plain wrong. The yielder is being nice, so it
>>should get preferential treatment, not worse treatment. All threads are
>>ready-to-run all the time. Yielding is not the same as blocking or lowering
>>your priority.
>In other words, the more you yield, the nicer you
>are and the more CPU you get, and those nasty processes
>that are trying to actually use the CPU to do something
>with it and wear it down should get it as little as possible.
>I get it.
>
> - Mgix
I'm sorry, but you are being entirely unreasonable. The kernel has no way to
know which processes are doing something useful and which ones are just
wasting CPU. It knows is that they are all ready-to-run and they all have the
same priority and none of them are blocking. The yielding threads are playing
nice and shouldn't be penalized for it.
The following code:
while(1) sched_yield();
Is the problem, not the kernel. You can't expect the kernel's ESP to figure
out that you really meant something else or that your process isn't really
doing anything useful.
If you didn't mean to burn the CPU in an endless loop, WHY DID YOU?
You should never call sched_yield in a loop like this unless your intent is
to burn the CPU until some other thread/process does something. Since you
rarely want to do this, you should seldom if ever call sched_yield in a loop.
What sched_yield is good for is if you encounter a situation where you
need/want some resource and another thread/process has it. You call
sched_yield once, and maybe when you run again, the other thread/process will
have released it. You can also use it as the spin function in spinlocks.
But your expectation that it will reduce CPU usage is just plain wrong. If
you have one thread spinning on sched_yield, on a single CPU machine it will
definitely get 100% of the CPU. If you have two, they will each definitely
get 50% of the CPU. There are blocking functions and scheduler priority
functions for this purpose.
DS
next prev parent reply other threads:[~2002-06-18 19:11 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-15 22:15 Question about sched_yield() mgix
2002-06-16 14:43 ` [patch] " Ingo Molnar
2002-06-18 0:46 ` David Schwartz
2002-06-18 0:55 ` Robert Love
2002-06-18 1:51 ` mgix
2002-06-18 3:18 ` David Schwartz
2002-06-18 9:36 ` David Schwartz
2002-06-18 16:58 ` Chris Friesen
2002-06-18 17:12 ` Richard B. Johnson
2002-06-18 17:19 ` mgix
2002-06-18 18:01 ` David Schwartz
2002-06-18 18:05 ` mgix
2002-06-18 19:11 ` David Schwartz [this message]
2002-06-18 16:58 ` Rob Landley
2002-06-18 19:25 ` Robert Love
2002-06-18 19:53 ` David Schwartz
2002-06-18 20:12 ` mgix
2002-06-18 20:42 ` David Schwartz
2002-06-18 20:47 ` mgix
2002-06-18 22:00 ` David Schwartz
2002-06-18 22:28 ` Ingo Molnar
2002-06-18 20:08 ` Richard B. Johnson
2002-06-19 11:10 ` Bill Davidsen
2002-06-19 12:04 ` Ingo Molnar
2002-06-18 22:43 ` Olivier Galibert
2002-06-18 18:21 ` Richard B. Johnson
2002-06-18 17:13 ` Robert Love
2002-06-18 18:00 ` David Schwartz
2002-06-18 22:45 ` Stevie O
2002-06-19 2:11 ` David Schwartz
2002-06-19 2:52 ` Stevie O
2002-06-20 20:31 ` David Schwartz
2002-06-18 17:23 ` Rik van Riel
2002-06-18 17:50 ` Chris Friesen
2002-06-18 1:41 ` mgix
2002-06-18 3:21 ` David Schwartz
2002-06-18 3:52 ` mgix
2002-06-18 4:55 ` Ingo Molnar
2002-06-19 11:24 ` Bill Davidsen
2002-06-19 11:47 ` scheduler timeslice distribution, threads, processes. [was: Re: Question about sched_yield()] Ingo Molnar
2002-06-18 18:56 ` Question about sched_yield() Rusty Russell
2002-06-18 19:12 ` David Schwartz
2002-06-18 20:19 ` Rusty Russell
2002-06-18 20:40 ` David Schwartz
2002-06-18 20:42 ` mgix
2002-06-18 22:03 ` David Schwartz
2002-06-18 22:36 ` Ingo Molnar
2002-06-19 11:29 ` Bill Davidsen
2002-06-19 14:03 ` Rusty Russell
2002-06-19 22:25 ` Bill Davidsen
2002-06-19 22:37 ` Ingo Molnar
2002-06-19 2:10 ` jw schultz
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=20020618191114.AAA27826@shell.webmaster.com@whenever \
--to=davids@webmaster.com \
--cc=cfriesen@nortelnetworks.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgix@mgix.com \
--cc=rml@tech9.net \
--cc=root@chaos.analogic.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