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 AE1876B0062 for ; Wed, 16 Dec 2009 05:16:23 -0500 (EST) Received: from m2.gw.fujitsu.co.jp ([10.0.50.72]) by fgwmail6.fujitsu.co.jp (Fujitsu Gateway) with ESMTP id nBGAGJdf014903 for (envelope-from kamezawa.hiroyu@jp.fujitsu.com); Wed, 16 Dec 2009 19:16:20 +0900 Received: from smail (m2 [127.0.0.1]) by outgoing.m2.gw.fujitsu.co.jp (Postfix) with ESMTP id 5B0A045DE5D for ; Wed, 16 Dec 2009 19:16:19 +0900 (JST) Received: from s2.gw.fujitsu.co.jp (s2.gw.fujitsu.co.jp [10.0.50.92]) by m2.gw.fujitsu.co.jp (Postfix) with ESMTP id 3B1E345DE51 for ; Wed, 16 Dec 2009 19:16:19 +0900 (JST) Received: from s2.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s2.gw.fujitsu.co.jp (Postfix) with ESMTP id F39BB1DB8043 for ; Wed, 16 Dec 2009 19:16:18 +0900 (JST) Received: from m105.s.css.fujitsu.com (m105.s.css.fujitsu.com [10.249.87.105]) by s2.gw.fujitsu.co.jp (Postfix) with ESMTP id 9F6861DB803B for ; Wed, 16 Dec 2009 19:16:18 +0900 (JST) Date: Wed, 16 Dec 2009 19:13:12 +0900 From: KAMEZAWA Hiroyuki Subject: Re: [mm][RFC][PATCH 0/11] mm accessor updates. Message-Id: <20091216191312.f4655dac.kamezawa.hiroyu@jp.fujitsu.com> In-Reply-To: <20091216101107.GA15031@basil.fritz.box> References: <20091216120011.3eecfe79.kamezawa.hiroyu@jp.fujitsu.com> <20091216101107.GA15031@basil.fritz.box> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org To: Andi Kleen Cc: "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , cl@linux-foundation.org, "akpm@linux-foundation.org" , "mingo@elte.hu" , minchan.kim@gmail.com List-ID: On Wed, 16 Dec 2009 11:11:07 +0100 Andi Kleen wrote: > On Wed, Dec 16, 2009 at 12:00:11PM +0900, KAMEZAWA Hiroyuki wrote: > > This is from Christoph Lameter's mm_accessor patch posted 5/Nov. > > > > Replacing all access to mm->mmap_sem with mm-accessor functions as > > mm_read_lock, > > mm_write_lock, > > etc... > > > > This kind of function allows us to improve page fault performance etc.. > > For example, skil down_read(mmap_sem) in some situation. > > (as: http://marc.info/?l=linux-mm&m=125809791306459&w=2) > > The problem is that it also slows down the writers, and we have > some workloads where writing is the bottleneck. > > I don't think this is the right trade off at this time. > Maybe you don't see my patch. (above URL) no slow down to write side. My one doesn't use percpu counter. > Also the patches didn't fare too well in testing unfortunately. > > I suspect we'll rather need multiple locks split per address > space range. This set doesn't include any changes of the logic. Just replace all mmap_sem. I think this is good start point (for introducing another logic etc..) Thanks, -Kame -- 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