Re: [patch] CFS scheduler, -v19

[Bill Davidsen <davidsen@tmr.com>]

Ingo Molnar wrote:
> * Ian Kent <raven@themaw.net> wrote:
>
>   
> > > > ah! It passes in a low-res time source into a high-res time 
> > > > interface (pthread_cond_timedwait()). Could you change the 
> > > > time(NULL) + 1 to time(NULL) + 2, or change it to:
> > > >
> > > > 	gettimeofday(&wait, NULL);
> > > > 	wait.tv_sec++;
> > > >
> > > > does this solve the spinning?
> > > >         
> > Yes, adding in the offset within the current second appears to resolve 
> > the issue. Thanks Ingo.
> >
> >     
> > > > i'm wondering how widespread this is. If automount is the only app 
> > > > doing this then _maybe_ we could get away with it by changing 
> > > > automount?
> > > >         
> > I don't think the change is unreasonable since I wasn't using an 
> > accurate time in the condition wait, so that's a coding mistake on my 
> > part which I will fix.
> >     
>
> thanks Ian for taking care of this and for fixing it!
>
> Linus, Thomas, what do you think, should we keep the time.c change? 
> Automount is one app affected so far, and it's a borderline case: the 
> increased (30%) CPU usage is annoying, but it does not prevent the 
> system from working per se, and an upgrade to a fixed/enhanced automount 
> version resolves it.
>
> The temptation of using a really (and trivially) scalable low-resolution 
> time-source (which is _easily_ vsyscall-able, on any platform) for DBMS 
> use is really large, to me at least. Should i perhaps add a boot/config 
> option that enables/disables this optimization, to allow distros finer
> grained control about this? And we've also got to wait whether there's
> any other app affected.
>   
Allow it to be selected by the "features" so that admins can evaluate 
the implications without a reboot?  That would be a convenient interface 
if you could provide it.

--
bill davidsen <davidsen@tmr.com>
 CTO TMR Associates, Inc
 Doing interesting things with small computers since 1979

-
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/