Messages in this thread | | | Date | Thu, 27 Sep 2007 11:30:02 +0200 | From | Jarek Poplawski <> | Subject | Re: Network slowdown due to CFS |
| |
On 26-09-2007 15:31, Ingo Molnar wrote: > * David Schwartz <davids@webmaster.com> wrote: > >>>> I think the real fix would be for iperf to use blocking network IO >>>> though, or maybe to use a POSIX mutex or POSIX semaphores. >>> So it's definitely not a bug in the kernel, only in iperf? >> Martin: >> >> Actually, in this case I think iperf is doing the right thing (though not >> the best thing) and the kernel is doing the wrong thing. [...] > > it's not doing the right thing at all. I had a quick look at the source > code, and the reason for that weird yield usage was that there's a > locking bug in iperf's "Reporter thread" abstraction and apparently > instead of fixing the bug it was worked around via a horrible yield() > based user-space lock. > > the (small) patch below fixes the iperf locking bug and removes the > yield() use. There are numerous immediate benefits of this patch: ... > > sched_yield() is almost always the symptom of broken locking or other > bug. In that sense CFS does the right thing by exposing such bugs =B-)
...Only if it were under some DEBUG option. Even if iperf is doing the wrong thing there is no explanation for such big difference in the behavior between sched_compat_yield 1 vs. 0. It seems common interfaces should work similarly and predictably on various systems, and here, if I didn't miss something, linux looks like a different kind?
Regards, Jarek P. - 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/
| |