From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail143.messagelabs.com (mail143.messagelabs.com [216.82.254.35]) by kanga.kvack.org (Postfix) with ESMTP id 3A9466B0012 for ; Fri, 17 Jun 2011 14:42:49 -0400 (EDT) Received: from mail-wy0-f169.google.com (mail-wy0-f169.google.com [74.125.82.169]) (authenticated bits=0) by smtp1.linux-foundation.org (8.14.2/8.13.5/Debian-3ubuntu1.1) with ESMTP id p5HIgG5w017583 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Fri, 17 Jun 2011 11:42:17 -0700 Received: by wyf19 with SMTP id 19so2572712wyf.14 for ; Fri, 17 Jun 2011 11:42:16 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <1308097798.17300.142.camel@schen9-DESK> <1308101214.15392.151.camel@sli10-conroe> <1308138750.15315.62.camel@twins> <20110615161827.GA11769@tassilo.jf.intel.com> <1308156337.2171.23.camel@laptop> <1308163398.17300.147.camel@schen9-DESK> <1308169937.15315.88.camel@twins> <4DF91CB9.5080504@linux.intel.com> <1308172336.17300.177.camel@schen9-DESK> <1308173849.15315.91.camel@twins> <1308255972.17300.450.camel@schen9-DESK> <1308310080.2355.19.camel@twins> <1308334688.12801.19.camel@laptop> <1308335557.12801.24.camel@laptop> From: Linus Torvalds Date: Fri, 17 Jun 2011 11:41:55 -0700 Message-ID: Subject: Re: REGRESSION: Performance regressions from switching anon_vma->lock to mutex Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-linux-mm@kvack.org List-ID: To: Peter Zijlstra Cc: Hugh Dickins , Tim Chen , Andi Kleen , Shaohua Li , Andrew Morton , KOSAKI Motohiro , Benjamin Herrenschmidt , David Miller , Martin Schwidefsky , Russell King , Paul Mundt , Jeff Dike , Richard Weinberger , "Luck, Tony" , KAMEZAWA Hiroyuki , Mel Gorman , Nick Piggin , Namhyung Kim , "Shi, Alex" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "Rafael J. Wysocki" On Fri, Jun 17, 2011 at 11:39 AM, Linus Torvalds wrote: > > Having gone over it a bit more, I actually think I prefer to just > special-case the allocation instead. Just to explain my thinking: the thing I disliked most about doing an allocation while holding the lock wasn't that I thought we would deadlock on page reclaim. I don't claim that kind of far-sight. No, the thing I disliked was that if we're low on memory and actually have to wait, I disliked having the lack of concurrency. I'm ok with holding the mutex over a few more CPU cycles, but anything longer might actually hurt throughput. So the patch I just sent out should fix both the page reclaim deadlock, and avoid any problems with delays due to holding the critical lock over an expensive allocation. 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org