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