linux-kernel - Re: [patch] CFS scheduler, -v19

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <469E1AA0.7030604@tmr.com>
Date:	Wed, 18 Jul 2007 09:50:24 -0400
From:	Bill Davidsen <davidsen@....com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Ian Kent <raven@...maw.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	davids@...master.com,
	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
	Chuck Ebbert <cebbert@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [patch] CFS scheduler, -v19

Ingo Molnar wrote:
> * Ian Kent <raven@...maw.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@....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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/