Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751346AbZLRXSj (ORCPT ); Fri, 18 Dec 2009 18:18:39 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750867AbZLRXSi (ORCPT ); Fri, 18 Dec 2009 18:18:38 -0500 Received: from fgwmail6.fujitsu.co.jp ([192.51.44.36]:49989 "EHLO fgwmail6.fujitsu.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750799AbZLRXSh (ORCPT ); Fri, 18 Dec 2009 18:18:37 -0500 Message-ID: <339143df87bf5d7afe89b9b2fe8af031.squirrel@webmail-b.css.fujitsu.com> In-Reply-To: <20091218184504.GA675@elte.hu> References: <20091217175338.GL9804@basil.fritz.box> <20091217190804.GB6788@linux.vnet.ibm.com> <20091217195530.GM9804@basil.fritz.box> <1261080855.27920.807.camel@laptop> <20091218051754.GC417@elte.hu> <4B2BB52A.7050103@redhat.com> <20091218171240.GB1354@elte.hu> <20091218184504.GA675@elte.hu> Date: Sat, 19 Dec 2009 08:18:33 +0900 (JST) Subject: Re: [mm][RFC][PATCH 0/11] mm accessor updates. From: "KAMEZAWA Hiroyuki" To: "Ingo Molnar" Cc: "Christoph Lameter" , "Avi Kivity" , "Peter Zijlstra" , "Andi Kleen" , "Paul E. McKenney" , "KAMEZAWA Hiroyuki" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "akpm@linux-foundation.org" , minchan.kim@gmail.com User-Agent: SquirrelMail/1.4.16 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-2022-jp Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1490 Lines: 46 Ingo Molnar wrote: > > * Christoph Lameter wrote: > >> > We've been through this many times in the past within the kernel: many >> > times when we hid some locking primitive within some clever wrapping >> > scheme the quality of locking started to deteriorate. In most of the >> > important cases we got rid of the indirection and went with an >> existing >> > core kernel locking primitive which are all well known and have clear >> > semantics and lead to more maintainable code. >> >> The existing locking APIs are all hiding lock details at various levels. >> We >> have various specific APIs for specialized locks already Page locking >> etc. > > You need to loo at the patches. This is simply a step backwards: > > - up_read(&mm->mmap_sem); > + mm_read_unlock(mm); > > because it hides the lock instance. > After rewriting speculative-page-fault patches, I feel I can do it without mm_accessor, by just skipping mmap_sem in fault.c. Then, original problem I tried to fix, false sharing at multithread page fault, can be fixed without this. Then, I myself stop this. About range-locking of mm_struct, I don't find any good approach. Sorry for annoying and thank you all. -Kame -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/