Cc: David Schwartz <davids@...>, Linux-Kernel@Vger. Kernel. Org <linux-kernel@...>, Mike Galbraith <efault@...>, Peter Zijlstra <a.p.zijlstra@...>, Martin Michlmayr <tbm@...>, Srivatsa Vaddagiri <vatsa@...>, Stephen Hemminger <shemminger@...>
note that i qualified my sentence both via "In that sense" and via a
smiley! So i was not suggesting that this is a general rule at all and i
was also joking :-)
What you missed is that there is no such thing as "predictable yield
behavior" for anything but SCHED_FIFO/RR tasks (for which tasks CFS does
keep the behavior). Please read this thread on lkml for a more detailed
background:
CFS: some bad numbers with Java/database threading [FIXED]
http://lkml.org/lkml/2007/9/19/357http://lkml.org/lkml/2007/9/19/328
in short: the yield implementation was tied to the O(1) scheduler, so
the only way to have the exact same behavior would be to have the exact
same core scheduler again. If what you said was true we would not be
able to change the scheduler, ever. For something as vaguely defined of
an API as yield, there's just no way to have a different core scheduler
and still behave the same way.
So _generally_ i'd agree with you that normally we want to be bug for
bug compatible, but in this specific (iperf) case there's just no point
in preserving behavior that papers over this _clearly_ broken user-space
app/thread locking (for which now two fixes exist already, plus a third
fix is the twiddling of that sysctl).
Ingo
-
