From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933131AbcLUK1S (ORCPT ); Wed, 21 Dec 2016 05:27:18 -0500 Received: from mail-pg0-f66.google.com ([74.125.83.66]:36031 "EHLO mail-pg0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932591AbcLUK1N (ORCPT ); Wed, 21 Dec 2016 05:27:13 -0500 Date: Wed, 21 Dec 2016 20:26:56 +1000 From: Nicholas Piggin To: Peter Zijlstra Cc: Linus Torvalds , Dave Hansen , Bob Peterson , Linux Kernel Mailing List , Steven Whitehouse , Andrew Lutomirski , Andreas Gruenbacher , Mel Gorman , linux-mm Subject: Re: [RFC][PATCH] make global bitlock waitqueues per-node Message-ID: <20161221202640.081cd4bf@roar.ozlabs.ibm.com> In-Reply-To: <20161221080931.GQ3124@twins.programming.kicks-ass.net> References: <20161219225826.F8CB356F@viggo.jf.intel.com> <156a5b34-ad3b-d0aa-83c9-109b366c1bdf@linux.intel.com> <20161221080931.GQ3124@twins.programming.kicks-ass.net> Organization: IBM X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 21 Dec 2016 09:09:31 +0100 Peter Zijlstra wrote: > On Tue, Dec 20, 2016 at 10:02:46AM -0800, Linus Torvalds wrote: > > On Tue, Dec 20, 2016 at 9:31 AM, Linus Torvalds > > wrote: > > > > > > I'll go back and try to see why the page flag contention patch didn't > > > get applied. > > > > Ahh, a combination of warring patches by Nick and PeterZ, and worry > > about the page flag bits. > > I think Nick actually had a patch freeing up a pageflag, although Hugh > had a comment on that. Yeah I think he basically acked it. It had a small compound debug false positive but I think it's okay. I'm just testing it again. > That said, I'm not a huge fan of his waiters patch, I'm still not sure > why he wants to write another whole wait loop, but whatever. Whichever > you prefer I suppose. Ah, I was waiting for some feedback, thanks. Well I wanted to do it that way to keep the manipulation of the new bit under the same lock as the waitqueue, so as not to introduce new memory orderings vs testing waitqueue_active. Thanks, Nick