Re: [patch] CFS scheduler, -v19

Bill Davidsen
2007-07-18T13:51:18Z

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