From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx126.postini.com [74.125.245.126]) by kanga.kvack.org (Postfix) with SMTP id 44D106B0044 for ; Sat, 1 Dec 2012 13:51:06 -0500 (EST) Received: by mail-we0-f169.google.com with SMTP id t49so649586wey.14 for ; Sat, 01 Dec 2012 10:51:04 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20121201184135.GA32449@gmail.com> References: <1354305521-11583-1-git-send-email-mingo@kernel.org> <20121201094927.GA12366@gmail.com> <20121201122649.GA20322@gmail.com> <20121201184135.GA32449@gmail.com> From: Linus Torvalds Date: Sat, 1 Dec 2012 10:50:44 -0800 Message-ID: Subject: Re: [RFC PATCH] mm/migration: Remove anon vma locking from try_to_unmap() use Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-linux-mm@kvack.org List-ID: To: Ingo Molnar Cc: Linux Kernel Mailing List , linux-mm , Peter Zijlstra , Paul Turner , Lee Schermerhorn , Christoph Lameter , Rik van Riel , Mel Gorman , Andrew Morton , Andrea Arcangeli , Thomas Gleixner , Johannes Weiner , Hugh Dickins On Sat, Dec 1, 2012 at 10:41 AM, Ingo Molnar wrote: > > I'll try the rwsem and see how it goes? Yeah. That should be an easy conversion (just convert everything to use the write-lock first, and then you can make one or two migration places use the read version). Side note: The mutex code tends to potentially generate slightly faster noncontended locks than rwsems, and it does have the MUTEX_SPIN_ON_OWNER feature that makes the contention case often *much* better, so there are real downsides to rw-semaphores. But for this load, it does seem like the scalability advantages of an rwsem *might* be worth it. Side note: in contrast, the rwlock spinning reader-writer locks are basically never a win - the downsides just about always negate any theoretical scalability advantage. rwsem's can work well, we already use it for mmap_sem, for example, to allow concurrent page faults, and it was a *big* scalabiloity win there. Although then we did the "drop mmap_sem over IO and retry", and that might have negated many of the advantages of the mmap_sem. > Hm, indeed. For performance runs I typically disable lock > debugging - which might have made me not directly notice some of > the performance problems. Yeah, lock debugging really tends to make anything that is close to contended be absolutely *horribly* contended. Doubly so for the mutexes because it disables the spinning code, but it's true in general too. Linus -- 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