> > There's a substantial performance hit for not yield, so we probablyThe 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 -
| Mark Lord | 2.6.25-rc8: FTP transfer errors |
| Kamalesh Babulal | Re: 2.6.23-rc6-mm1 |
| Greg Kroah-Hartman | [PATCH 025/196] paride: Convert from class_device to device for block/paride |
| Stephen Rothwell | Announce: Linux-next (Or Andrew's dream :-)) |
git: | |
| Linus Torvalds | Re: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49 |
| David Miller | Re: [GIT]: Networking |
| Gerrit Renker | [PATCH 18/37] dccp: Support for Mandatory options |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
