Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754564Ab3I1Sz3 (ORCPT ); Sat, 28 Sep 2013 14:55:29 -0400 Received: from mail-vb0-f53.google.com ([209.85.212.53]:64339 "EHLO mail-vb0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752479Ab3I1Sz1 (ORCPT ); Sat, 28 Sep 2013 14:55:27 -0400 MIME-Version: 1.0 In-Reply-To: <20130928074144.GA17773@gmail.com> References: <1380308424-31011-1-git-send-email-Waiman.Long@hp.com> <20130928074144.GA17773@gmail.com> Date: Sat, 28 Sep 2013 11:55:26 -0700 X-Google-Sender-Auth: WPVcdbynsVVNCoExDw26WY7eXsk Message-ID: Subject: Re: [PATCH] rwsem: reduce spinlock contention in wakeup code path From: Linus Torvalds To: Ingo Molnar Cc: Waiman Long , Ingo Molnar , Andrew Morton , Linux Kernel Mailing List , Rik van Riel , Peter Hurley , Davidlohr Bueso , Alex Shi , Tim Chen , Peter Zijlstra , Andrea Arcangeli , Matthew R Wilcox , Dave Hansen , Michel Lespinasse , Andi Kleen , "Chandramouleeswaran, Aswin" , "Norton, Scott J" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1679 Lines: 46 On Sat, Sep 28, 2013 at 12:41 AM, Ingo Molnar wrote: > > > Yeah, I fully agree. The reason I'm still very sympathetic to Tim's > efforts is that they address a regression caused by a mechanic > mutex->rwsem conversion: > > 5a505085f043 mm/rmap: Convert the struct anon_vma::mutex to an rwsem > > ... and Tim's patches turn that regression into an actual speedup. Btw, I really hate that thing. I think we should turn it back into a spinlock. None of what it protects needs a mutex or an rwsem. Because you guys talk about the regression of turning it into a rwsem, but nobody talks about the *original* regression. And it *used* to be a spinlock, and it was changed into a mutex back in 2011 by commit 2b575eb64f7a. That commit doesn't even have a reason listed for it, although my dim memory of it is that the reason was preemption latency. And that caused big regressions too. Of course, since then, we may well have screwed things up and now we sleep under it, but I still really think it was a mistake to do it in the first place. So if the primary reason for this is really just that f*cking anon_vma lock, then I would seriously suggest: - turn it back into a spinlock (or rwlock_t, since we subsequently separated the read and write paths) - fix up any breakage (ie new scheduling points) that exposes - look at possible other approaches wrt latency on that thing. Hmm? Linus -- 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/