On Mon, 2007-10-01 at 09:49 -0700, David Schwartz wrote:This used to be true, and still is if you want to be portable. But the point of futexes was precisely to attack this use case: whereas sched_yield() says "I'm waiting for something, but I won't tell you what" the futex ops tells the kernel what you're waiting for. While the time to do a futex op is slightly slower than sched_yield(), futexes win in so many cases that we haven't found a benchmark where yield wins. Yield-lose cases include: 1) There are other unrelated process that yield() ends up queueing behind. 2) The process you're waiting for doesn't conveniently sleep as soon as it releases the lock, so you wait for longer than intended, 3) You race between the yield and the lock being dropped. In summary: spin N times & futex seems optimal. The value of N depends on the number of CPUs in the machine and other factors, but N=1 has shown itself pretty reasonable. Hope that helps, Rusty. -
| debian developer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 014/196] kobject: remove incorrect comment in kobject_rename |
| Vladislav Bolkhovitin | Re: Integration of SCST in the mainstream Linux kernel |
| Stephen Rothwell | Re: Announce: Linux-next (Or Andrew's dream :-)) |
git: | |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | [GIT]: Networking |
| Radu Rendec | htb parallelism on multi-core platforms |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
