On Thu, 2003-05-01 at 01:21, Andrew Morton wrote:
> Rick Lindsley <[email protected]> wrote:
> >
> > Why is this bad?
> > (a) if it does busy looping through sched_yield it will eat cycles which
> > might not have happened
>
> Things like OpenOffice _do_ busy loop on sched_yield(). It appears with
> that patch, OO will sit there chewing ~1% of CPU. Not great, but not bad
> either..
>
> A few kernels ago, OpenOffice would take sixty seconds to just flop down a
> menu if there was a kernel build happening at the same time. That is just
> utterly broken, so if we're going to leave the sched.c code as-is then we
> *require* that all applications be updated to not spin on sched_yield.
>
> There's just no question about that. It may end up not being acceptable.
actually this is an ooffice bug and is since fixed..... newer ooffice
versions don't have this behavior anymore. Nuking a kernel feature
(basically making sched_yield() more posix compliant) for ONE
broken-since-fixed app doesn't sound like a good plan to me.
Arjan van de Ven <[email protected]> wrote:
>
> Nuking a kernel feature
> (basically making sched_yield() more posix compliant) for ONE
> broken-since-fixed app doesn't sound like a good plan to me.
You're promising there are no others?
On Thu, May 01, 2003 at 01:42:12AM -0700, Andrew Morton wrote:
> Arjan van de Ven <[email protected]> wrote:
> >
> > Nuking a kernel feature
> > (basically making sched_yield() more posix compliant) for ONE
> > broken-since-fixed app doesn't sound like a good plan to me.
>
> You're promising there are no others?
I'm saying that about half the others will expect the new (posix) behavior
and half will expect the old linux behavior of yielding only 1 spot.
Whatever you do you can't win for everything; and the vast majority of the
apps out there will not even call this function themselves. Ever.