From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail172.messagelabs.com (mail172.messagelabs.com [216.82.254.3]) by kanga.kvack.org (Postfix) with SMTP id C39CC6B0062 for ; Tue, 24 Nov 2009 10:18:36 -0500 (EST) Date: Tue, 24 Nov 2009 09:17:40 -0600 (CST) From: Christoph Lameter Subject: Re: [MM] Make mm counters per cpu instead of atomic In-Reply-To: <1259049753.29789.49.camel@localhost> Message-ID: References: <1258440521.11321.32.camel@localhost> <1258443101.11321.33.camel@localhost> <1258450465.11321.36.camel@localhost> <1258966270.29789.45.camel@localhost> <1259049753.29789.49.camel@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org To: "Zhang, Yanmin" Cc: KAMEZAWA Hiroyuki , "hugh.dickins@tiscali.co.uk" , linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, Tejun Heo , Andi Kleen List-ID: On Tue, 24 Nov 2009, Zhang, Yanmin wrote: > > True.... We need to find some alternative to per cpu data to scale mmap > > sem then. > I ran lots of benchmarks such like specjbb2005/hackbench/tbench/dbench/iozone > /sysbench_oltp(mysql)/aim7 against percpu tree(based on 2.6.32-rc7) on a 4*8*2 logical > cpu machine, and didn't find big result difference between with your patch and without > your patch. This affects loads that heavily use mmap_sem. You wont find too many issues in tests that do not run processes with a large thread count and cause lots of faults or uses of get_user_pages(). The tests you list are not of that nature. -- 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