linux-kernel - Re: [rfc] no ZERO

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, 4 Apr 2007 09:14:14 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Hugh Dickins <hugh@...itas.com>
cc:	Andrea Arcangeli <andrea@...e.de>, Dan Aloni <da-x@...atomic.org>,
	Nick Piggin <npiggin@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Memory Management List <linux-mm@...ck.org>,
	tee@....com, holt@....com,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [rfc] no ZERO_PAGE?

On Wed, 4 Apr 2007, Hugh Dickins wrote:

> On Wed, 4 Apr 2007, Andrea Arcangeli wrote:
> > On Wed, Apr 04, 2007 at 04:03:15PM +0100, Hugh Dickins wrote:
> > > Maybe Nick will decide to not to mark the readfaults as dirty.
> > 
> > I don't like to mark the pte readonly and clean,
> 
> Nor I: I meant that anonymous readfault should
> (perhaps) mark the pte writable but clean.

Maybe. On the other hand, marking it dirty is going to be almost as 
expensive as taking the whole page fault again. The dirty bit is in 
software on a lot of architectures, and even on x86 where it's in hw, all 
microarchitectures basically consider it a micro-trap, and some of them 
(*cough*P4*cough*) are really bad at it.

So I'd actually rather just mark it dirty too, because that way there is a 
real potential performance upside to go with the real potential 
performance downside, and we can hope that it all comes out even in the 
end ;)

			Linus

PS. Yes, I wrote the benchmark. On at least some versions of the P4, just 
setting the dirty bit took 1500 cycles.. No sw-visible traps, just a *lot* 
of cycles to clean out the pipeline entirely, do a micro-trap, and 
continue. Of course, the P4 sucks at these things, but the point is that 
it can be as expensive to do it "in hardware" as doing it in software if 
the hardware is mis-designed..
-
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/