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]

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

* 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.

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