Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761633AbcLUSCb (ORCPT ); Wed, 21 Dec 2016 13:02:31 -0500 Received: from mail-it0-f68.google.com ([209.85.214.68]:36623 "EHLO mail-it0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1761553AbcLUSC2 (ORCPT ); Wed, 21 Dec 2016 13:02:28 -0500 MIME-Version: 1.0 In-Reply-To: <20161221083247.GW3174@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> <20161221083247.GW3174@twins.programming.kicks-ass.net> From: Linus Torvalds Date: Wed, 21 Dec 2016 10:02:27 -0800 X-Google-Sender-Auth: CiUE1cJLAGqDcAqt9VQL76ASRJs Message-ID: Subject: Re: [RFC][PATCH] make global bitlock waitqueues per-node To: Peter Zijlstra , Nick Piggin Cc: Dave Hansen , Bob Peterson , Linux Kernel Mailing List , Steven Whitehouse , Andrew Lutomirski , Andreas Gruenbacher , Mel Gorman , linux-mm 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: 1534 Lines: 36 On Wed, Dec 21, 2016 at 12:32 AM, Peter Zijlstra wrote: > > FWIW, here's mine.. compiles and boots on a NUMA x86_64 machine. So I like how your patch is smaller, but your patch is also broken. First off, the whole contention bit is *not* NUMA-specific. It should help non-NUMA too, by avoiding the stupid extra cache miss. Secondly, CONFIG_NUMA is a broken thing to test anyway, since adding a bit for the NUMA case can overflow the page flags as far as I can tell (MIPS seems to support NUMA on 32-bit, for example, but I didn't really check the Kconfig details). Making it dependent on 64-bit might be ok (and would fix the issue above - I don't think we really need to care too much about 32-bit any more) But making it conditional at all means that now you have those two different cases for this, which is a maintenance nightmare. So don't do it even if we could say "screw 32-bit". Anyway, the conditional thing could be fixed by just taking Nick's patch 1/2, and your patch (with the conditional bits stripped out). I do think your approach of just re-using the existing bit waiting with just a page-specific waiting function is nicer than Nick's "let's just roll new waiting functions" approach. It also avoids the extra initcall. Nick, comments? Hugh - mind testing PeterZ's patch too? My comments about the conditional PG_waiters bit and page bit overflow are not relevant for your particular scenario, so you can ignore that part, and just take PaterZ's patch directly. Linus