linux-kernel - Re: AIM7 40% regression with 2.6.26-rc1

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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 7 May 2008 19:36:12 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Andi Kleen <andi@...stfloor.org>, Matthew Wilcox <matthew@....cx>,
	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Alexander Viro <viro@....linux.org.uk>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: AIM7 40% regression with 2.6.26-rc1


* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> 
> 
> On Wed, 7 May 2008, Ingo Molnar wrote:
> > 
> > it was removed by me in the course of this discussion:
> > 
> >    http://lkml.org/lkml/2008/1/2/58
> > 
> > the whole discussion started IIRC because !CONFIG_PREEMPT_BKL [the 
> > spinlock version] was broken for a longer period of time (it crashed 
> > trivially), because nobody apparently used it.
> 
> Hmm. I've generally used PREEMPT_NONE, and always thought PREEMPT_BKL 
> was the known-flaky one.
> 
> The thread you point to also says that it's PREEMPT_BKL=y that was the 
> problem (ie "I've seen 1s+ desktop latencies due to PREEMPT_BKL when I 
> was still using reiserfs."), not the plain spinlock approach.

no, there was another problem (which i couldnt immediately find because 
lkml.org only indexes part of the threads, i'll research it some more), 
which was some cond_resched() thing in the !PREEMPT_BKL case.

> But it would definitely be interesting to see the crash reports. And 
> the help message always said "Say N if you are unsure." even if it 
> ended up being marked 'y' by default at some point (and then in 
> January was made first unconditional, and then removed entirely)
> 
> Because in many ways, the non-preempt BKL is the *much* simpler case. 
> I don't see why it would crash - it just turns the BKL into a trivial 
> counting spinlock that can sleep.

yeah. The latencies are a different problem, and indeed were reported 
against PREEMPT_BKL, and believed to be due to reiser3 and the tty code. 
(reiser3 runs almost all of its code under the BKL)

The !PREEMPT_BKL crash was some simple screwup on my part of getting 
atomicity checks wrong in cond_resched() - and it went unnoticed for a 
long time - or something like that. I'll try to find that discussion.

	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/