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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jun 23 2002 - 22:00:17 EST