Re: [rfc] no ZERO_PAGE?

[Dan Aloni <da-x@monatomic.org>]

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