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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/