> > 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).
> >
>
> OK, but let's forget about fixing iperf. Probably I got this wrong,
> but I've thought this "bad" iperf patch was tested on a few nixes and
> linux was the most different one. The main point is: even if there is
> no standard here, it should be a common interest to try to not differ
> too much at least. So, it's not about exactness, but 50% (63 -> 95)
> change in linux own 'definition' after upgrading seems to be a lot.
> So, IMHO, maybe some 'compatibility' test could be prepared to compare
> a few different ideas on this yield and some average value could be a
> kind of at least linux' own standard, which should be emulated within
> some limits by next kernels?
