linux-kernel - Re: [git pull] scheduler fixes

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: <20080513144207.GA4697@elte.hu>
Date:	Tue, 13 May 2008 16:42:07 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Matthew Wilcox <matthew@....cx>
Cc:	Sven Wegener <sven.wegener@...aler.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
	Andi Kleen <andi@...stfloor.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Alexander Viro <viro@....linux.org.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [git pull] scheduler fixes


* Matthew Wilcox <matthew@....cx> wrote:

> > a 50% AIM7 slowdown maybe? With the BKL being a spinlock again it 
> > doesnt matter much in practice though.
> 
> You're not understanding me.  This is completely inapplicable to the 
> BKL because only one task can be in wakeup at a time (due to it having 
> a maximum value of 1).  There's no way to hit this race with the BKL. 
> The only kind of semaphore that can hit this race is the kind that can 
> have more than one wakeup in progress at a time -- ie one which can 
> have a value >1.  Like completions and real counting semaphores.

yes, but even for parallel wakeups for completions it's good in general 
to keep more tasks in flight than to keep less tasks in flight.

Perhaps the code could throttle them to nr_cpus, but otherwise, as the 
BKL example has shown it (in another context), we do much better if we 
overload the scheduler (in which case it can and does batch 
intelligently) than if we try to second-guess it and under-load it and 
create lots of scheduling events.

i'd agree with you that are no numbers available pro or contra, so you 
are right that my 50% point does not apply to your argument.

> So the only thing worth talking about (and indeed, it's now entirely 
> moot) is what's the best way to solve this problem /for this kind of 
> semaphore/.

it's not really moot in terms of improving the completions code i 
suspect? For XFS i guess performance matters.

	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/