From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail190.messagelabs.com (mail190.messagelabs.com [216.82.249.51]) by kanga.kvack.org (Postfix) with SMTP id 50E266B01AE for ; Thu, 25 Mar 2010 18:42:24 -0400 (EDT) Date: Thu, 25 Mar 2010 23:41:19 +0100 From: Andrea Arcangeli Subject: Re: [PATCH 00 of 34] Transparent Hugepage support #14 Message-ID: <20100325224119.GY10659@random.random> References: <20100318234923.GV29874@random.random> <20100319144101.GB29874@random.random> <20100322170619.GQ29874@random.random> <20100323190805.GH10659@random.random> <20100324212249.GI10659@random.random> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org To: Christoph Lameter Cc: linux-mm@kvack.org, Marcelo Tosatti , Adam Litke , Avi Kivity , Izik Eidus , Hugh Dickins , Nick Piggin , Rik van Riel , Mel Gorman , Dave Hansen , Benjamin Herrenschmidt , Ingo Molnar , Mike Travis , KAMEZAWA Hiroyuki , Chris Wright , bpicco@redhat.com, KOSAKI Motohiro , Balbir Singh , Arnd Bergmann , "Michael S. Tsirkin" , Peter Zijlstra List-ID: On Thu, Mar 25, 2010 at 05:17:23PM -0500, Christoph Lameter wrote: > On Wed, 24 Mar 2010, Andrea Arcangeli wrote: > > > On Wed, Mar 24, 2010 at 04:03:03PM -0500, Christoph Lameter wrote: > > > If a delay is "altered behavior" then we should no longer run reclaim > > > because it "alters" the behavior of VM functions. > > > > You're comparing the speed of ram with speed of disk. If why it's not > > acceptable to me isn't clear try booting with mem=100m and I'm sure > > you'll get it. > > Are you talking about the wait for writeback to be complete? Dirty pages > can be migrated. With some effort you could avoid the writeback complete > wait since you are not actually moving the page. It seems we're derailing, let's try to go back to the context. You said we can avoid get_page/put_page changes if we do like migration. Migration bails out if there's a gup reference on the page. It's _gup_ not writeback we're talking about. gup is used for I/O too like O_DIRECT (which is mandatory feature for virtual machines, if not for databases). So the I/O I'm talking about is the one that any driver or subsystem can do after calling gup. And it's not a lock on the page or a writeback bitflag, but the gup reference that we're waiting the I/O to complete, in order to be released. Not to tell drivers like old KVM pre-mmu-notifier that may never release the gup reference (these days any driver keeping gup references for "indefinite" time has to use mmu notifier to play nicely with the VM but there will always be temporary I/O at the speed-of-disk and hanging mprotect and mremap on that isn't ok with me). -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org