>
> > [...] 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?
>
> 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/357
>
http://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).
>
