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 19:15:15 +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 05:27:17PM +0200, Andrea Arcangeli wrote:
> On Wed, Apr 04, 2007 at 05:44:21PM +0300, Dan Aloni wrote:
> > 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? 
> 
> Swapout or ram is the same in this context. The point is that it will
> take 4k either in ram or swap, let's talk about virtual memory without
> differentiating between ram or swap.

The main difference is that disk-backed swap can create I/O pressure which
would slow down the swap-outs that are not of zeroed pages (and other I/Os
on that disk for that matter). For purely-RAM virtual memory the latency 
incured from managing newly allocated and zeroed pages is neglegible 
compared to the latencies you get from reading/flushing those pages to 
disk if you add swap to the picture.
 
> > Perhaps it's an example too far-fetched to worth considering...
> 
> Even if you would read the sparsed file to a malloced space (more
> commonly that would be tmpfs) using the read syscall, those anon (or
> tmpfs) pages would be _written_ first, which isn't the case we're
> discussing here.
> 
> You don't know what is on disk, so reading from disk (regardless of
> what you read, holes, zeros or anything) provides useful information,
> but you know what is in ram after an anon mmap: just zeros, reading
> them can't provide useful information to any software.

I agree. The swap I/O case still holds, though: swapping-in the zeroed
pages that got swapped-out might incur unwanted overhead.

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

Powered by blists - more mailing lists