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 18:48:48 +0200
From:	Andrea Arcangeli <andrea@...e.de>
To:	Dan Aloni <da-x@...atomic.org>
Cc:	Linux Memory Management List <linux-mm@...ck.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [rfc] no ZERO_PAGE?

Hi Dan,

On Wed, Apr 04, 2007 at 07:15:15PM +0300, Dan Aloni wrote:
> 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.

Sorry but you're telling me the obvious... clearly you're right, swap
is slower, ram is faster. As a corollary on a 64bit system you could
always throw money at ram and _guarantee_ that those anon read page
faults never hit swap. That's not the point.

If 4G more of virtual memory are allocated in the address space of a
task because of this kernel change, it's the same problem if those 4G
are later allocated in swap or in ram depending on the runtime
environment of the kernel. The problem is that 4G more will be
allocated, it doesn't matter _where_. The user with a 8G system will
not be slowed down much, the user with a 128M system will trash beyond
repair, but it's the same problem for both. If the new ram will go
into ram or swap is irrelevant because it's an unknown variable that
depends on the amount of ram and swap and on what else is running
(infact there will be a third guy with even less luck that will go out
of memory and crash after hitting an oom killer bug ;), it's the same
problem in all three cases.
-
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/