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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Wed, 4 Apr 2007 17:44:21 +0300
From:	Dan Aloni <da-x@...atomic.org>
To:	Andrea Arcangeli <andrea@...e.de>
Cc:	Nick Piggin <npiggin@...e.de>, Hugh Dickins <hugh@...itas.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...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, Apr 04, 2007 at 04:14:57PM +0200, Andrea Arcangeli wrote:
> On Wed, Apr 04, 2007 at 04:55:32PM +0300, Dan Aloni wrote:
> > How about applications that perform mmap() and R/W random-access on 
> > large *sparse* files? (e.g. a scientific app that uses a large sparse 
> > file as a big database look-up table). As I see it, these apps would
> > need to keep track of what's sparse and what's not...
> 
> That's not anonymous memory if those are read page faults on
> _files_. I'm only talking about anonymous memory and
> do_anonymous_page, i.e. no file data at all. In more clear words, the
> only thing we're discussing here is char = malloc(1); *char.
>
> Your example _already_ allocates zeroed pagecache instead of the zero
> page, so your example (random access over sparse files with mmap, be
> it MAP_PRIVATE or MAP_SHARED no difference for reads) has never had
> anything to do with the zero page. If something we could optimize your
> example to _start_ using for the first time ever the ZERO_PAGE, it
> would make more sense to use it to be mapped where the lowlevel fs
> finds holes. ZERO_PAGE in do_anonymous_page instead doesn't make much
> sense to me, but it has always been there as far as I can
> remember. The thing is that it never hurted until the huge systems
> with nightmare cacheline bouncing reported heavy stalls on some
> testcase, which make it look like a DoS because of the ZERO_PAGE,
> hence now that it hurts I guess it can go.

Oh, right. Thanks for clarifing. I should have figured it out before 
I sent that mail.

To refine that example, you could replace the file with a large anonymous 
memory pool and a lot of swap space committed to it. In that case - with 
no ZERO_PAGE, would the kernel needlessly swap-out the zeroed pages? 
Perhaps it's an example too far-fetched to worth considering...

-- 
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il
-
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/