From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail202.messagelabs.com (mail202.messagelabs.com [216.82.254.227]) by kanga.kvack.org (Postfix) with SMTP id 1F0FF6B0044 for ; Fri, 18 Dec 2009 09:30:45 -0500 (EST) Date: Fri, 18 Dec 2009 15:30:25 +0100 From: Andrea Arcangeli Subject: Re: [PATCH 02 of 28] alter compound get_page/put_page Message-ID: <20091218143025.GJ29790@random.random> References: <1bc7617980f2f148888e.1261076405@v2.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 , Andi Kleen , Dave Hansen , Benjamin Herrenschmidt , Ingo Molnar , Mike Travis , KAMEZAWA Hiroyuki , Chris Wright , Andrew Morton List-ID: On Thu, Dec 17, 2009 at 01:50:10PM -0600, Christoph Lameter wrote: > > Additional cachelines are dirtied in performance critical VM primitives > now. Increases cache footprint etc. Only slowdown added is to put_page called on compound _tail_ pages. Everything runs as fast as always on regular pages, hugetlbfs head pages, and transparent head hugepages too the same way. The only thing that ever calls a put_page on a compound tail page is O_DIRECT I/O completion handler which is all but performance critical given it is I/O dominated. The ones that aren't I/O dominated and that don't deal with I/O DMA (like KVM minor fault and GRU tlb miss handler), must start using mmu notifier and stop calling gup with FOLL_GET and not ever need to call put_page at all, so they will run faster with or without 2/28 (and they won't screw with KSM merging [ksm can't merge if there are pins on the pages to avoids screwing in-flight dma], and they will be pageable). -- 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