From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Date: Tue, 24 Sep 2019 12:43:25 +0000 Subject: Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware Message-Id: <20190924124325.GQ2349@hirez.programming.kicks-ass.net> List-Id: References: <20190923154852.GG2369@hirez.programming.kicks-ass.net> <20190923165235.GD17206@dhcp22.suse.cz> <20190923203410.GI2369@hirez.programming.kicks-ass.net> <20190924074751.GB23050@dhcp22.suse.cz> <20190924091714.GJ2369@hirez.programming.kicks-ass.net> <20190924105622.GH23050@dhcp22.suse.cz> <20190924112349.GJ2332@hirez.programming.kicks-ass.net> <20190924115401.GM23050@dhcp22.suse.cz> <20190924120943.GP2349@hirez.programming.kicks-ass.net> <20190924122500.GP23050@dhcp22.suse.cz> In-Reply-To: <20190924122500.GP23050@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Michal Hocko Cc: Yunsheng Lin , catalin.marinas@arm.com, will@kernel.org, mingo@redhat.com, bp@alien8.de, rth@twiddle.net, ink@jurassic.park.msu.ru, mattst88@gmail.com, benh@kernel.crashing.org, paulus@samba.org, mpe@ellerman.id.au, heiko.carstens@de.ibm.com, gor@linux.ibm.com, borntraeger@de.ibm.com, ysato@users.sourceforge.jp, dalias@libc.org, davem@davemloft.net, ralf@linux-mips.org, paul.burton@mips.com, jhogan@kernel.org, jiaxun.yang@flygoat.com, chenhc@lemote.com, akpm@linux-foundation.org, rppt@linux.ibm.com, anshuman.khandual@arm.com, tglx@linutronix.de, cai@lca.pw, robin.murphy@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, hpa@zytor.com, x86@kernel.org, dave.hansen@linux.intel.com, luto@kernel.org, len.brown@intel.com, axboe@kernel.dk, dledford@redhat.com, jeffrey.t.kirsher@intel.com, linux-alpha@vger.kernel.org, naveen.n.rao@linux.vnet.ibm.com, mwb@linux.vnet.ibm.com, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, tbogendoerfer@suse.de, linux-mips@vger.kernel.org, rafael@kernel.org, gregkh@linuxfoundation.org On Tue, Sep 24, 2019 at 02:25:00PM +0200, Michal Hocko wrote: > On Tue 24-09-19 14:09:43, Peter Zijlstra wrote: > > We can push back and say we don't respect the specification because it > > is batshit insane ;-) > > Here is my fingers crossed. > > [...] > > > Now granted; there's a number of virtual devices that really don't have > > a node affinity, but then, those are not hurt by forcing them onto a > > random node, they really don't do anything. Like: > > Do you really consider a random node a better fix than simply living > with a more robust NUMA_NO_NODE which tells the actual state? Page > allocator would effectivelly use the local node in that case. Any code > using the cpumask will know that any of the online cpus are usable. For the pmu devices? Yes, those 'devices' aren't actually used for anything other than sysfs entries. Nothing else uses the struct device. > Compare that to a wild guess that might be easily wrong and have subtle > side effects which are really hard to debug. You will only see a higher > utilization on a specific node. Good luck with a bug report like that. We'd have the FW_BUG in the dmesg, which should be a big fat clue. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BBEB3C432C1 for ; Tue, 24 Sep 2019 12:45:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 882F6214DA for ; Tue, 24 Sep 2019 12:45:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="WIMYj2tR" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2504963AbfIXMpA (ORCPT ); Tue, 24 Sep 2019 08:45:00 -0400 Received: from merlin.infradead.org ([205.233.59.134]:48768 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2439119AbfIXMo7 (ORCPT ); Tue, 24 Sep 2019 08:44:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=z5wfISW69eZ/kWXd4xS3/YcskS/mxFjheiW7ixIex14=; b=WIMYj2tRUrC7JYkCCQxCqzPmr eY7v/diobkQ+WLbrXSbzwyxW4iMZCZphUYFSPt9rrDdGl9ZKXo2i0OceglW9WDcIPsjHcxD15Qc2Y K9ozUDMls72WuTWCN/TorFuAf4A6PAQ5Xh0ACawwLZJ3mXrTTg1uJPW5mjf7w7vC5NgBQBysGTU3U np6ZtqoWQ0GKmiKv0p0ouxKN6kL4WmFc01pnfZxtbBI58YXEugJXvMXqBuEOAvfAG3Jp3qPhZ64vT Mxyw8HrGyIIAC9fvxv9ZzX7kCmie2FgIcHYDOFNNUFZSLhS4fE7hRJwacFZpyQ7/PXoAr3A3VCJbg mK0txX+5A==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by merlin.infradead.org with esmtpsa (Exim 4.92.2 #3 (Red Hat Linux)) id 1iCkAF-0000Nf-M0; Tue, 24 Sep 2019 12:43:31 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 17485305E35; Tue, 24 Sep 2019 14:42:40 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id AD4FF20D83742; Tue, 24 Sep 2019 14:43:25 +0200 (CEST) Date: Tue, 24 Sep 2019 14:43:25 +0200 From: Peter Zijlstra To: Michal Hocko Cc: Yunsheng Lin , catalin.marinas@arm.com, will@kernel.org, mingo@redhat.com, bp@alien8.de, rth@twiddle.net, ink@jurassic.park.msu.ru, mattst88@gmail.com, benh@kernel.crashing.org, paulus@samba.org, mpe@ellerman.id.au, heiko.carstens@de.ibm.com, gor@linux.ibm.com, borntraeger@de.ibm.com, ysato@users.sourceforge.jp, dalias@libc.org, davem@davemloft.net, ralf@linux-mips.org, paul.burton@mips.com, jhogan@kernel.org, jiaxun.yang@flygoat.com, chenhc@lemote.com, akpm@linux-foundation.org, rppt@linux.ibm.com, anshuman.khandual@arm.com, tglx@linutronix.de, cai@lca.pw, robin.murphy@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, hpa@zytor.com, x86@kernel.org, dave.hansen@linux.intel.com, luto@kernel.org, len.brown@intel.com, axboe@kernel.dk, dledford@redhat.com, jeffrey.t.kirsher@intel.com, linux-alpha@vger.kernel.org, naveen.n.rao@linux.vnet.ibm.com, mwb@linux.vnet.ibm.com, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, tbogendoerfer@suse.de, linux-mips@vger.kernel.org, rafael@kernel.org, gregkh@linuxfoundation.org Subject: Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware Message-ID: <20190924124325.GQ2349@hirez.programming.kicks-ass.net> References: <20190923154852.GG2369@hirez.programming.kicks-ass.net> <20190923165235.GD17206@dhcp22.suse.cz> <20190923203410.GI2369@hirez.programming.kicks-ass.net> <20190924074751.GB23050@dhcp22.suse.cz> <20190924091714.GJ2369@hirez.programming.kicks-ass.net> <20190924105622.GH23050@dhcp22.suse.cz> <20190924112349.GJ2332@hirez.programming.kicks-ass.net> <20190924115401.GM23050@dhcp22.suse.cz> <20190924120943.GP2349@hirez.programming.kicks-ass.net> <20190924122500.GP23050@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190924122500.GP23050@dhcp22.suse.cz> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 24, 2019 at 02:25:00PM +0200, Michal Hocko wrote: > On Tue 24-09-19 14:09:43, Peter Zijlstra wrote: > > We can push back and say we don't respect the specification because it > > is batshit insane ;-) > > Here is my fingers crossed. > > [...] > > > Now granted; there's a number of virtual devices that really don't have > > a node affinity, but then, those are not hurt by forcing them onto a > > random node, they really don't do anything. Like: > > Do you really consider a random node a better fix than simply living > with a more robust NUMA_NO_NODE which tells the actual state? Page > allocator would effectivelly use the local node in that case. Any code > using the cpumask will know that any of the online cpus are usable. For the pmu devices? Yes, those 'devices' aren't actually used for anything other than sysfs entries. Nothing else uses the struct device. > Compare that to a wild guess that might be easily wrong and have subtle > side effects which are really hard to debug. You will only see a higher > utilization on a specific node. Good luck with a bug report like that. We'd have the FW_BUG in the dmesg, which should be a big fat clue. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B5E4AC432C1 for ; Tue, 24 Sep 2019 12:47:04 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id ED779207FD for ; Tue, 24 Sep 2019 12:47:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="WIMYj2tR" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ED779207FD Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 46d1D54Gj6zDqV5 for ; Tue, 24 Sep 2019 22:47:01 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=none (mailfrom) smtp.mailfrom=infradead.org (client-ip=2001:8b0:10b:1231::1; helo=merlin.infradead.org; envelope-from=peterz@infradead.org; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=infradead.org header.i=@infradead.org header.b="WIMYj2tR"; dkim-atps=neutral Received: from merlin.infradead.org (merlin.infradead.org [IPv6:2001:8b0:10b:1231::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 46d19567GyzDqRS for ; Tue, 24 Sep 2019 22:44:25 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=z5wfISW69eZ/kWXd4xS3/YcskS/mxFjheiW7ixIex14=; b=WIMYj2tRUrC7JYkCCQxCqzPmr eY7v/diobkQ+WLbrXSbzwyxW4iMZCZphUYFSPt9rrDdGl9ZKXo2i0OceglW9WDcIPsjHcxD15Qc2Y K9ozUDMls72WuTWCN/TorFuAf4A6PAQ5Xh0ACawwLZJ3mXrTTg1uJPW5mjf7w7vC5NgBQBysGTU3U np6ZtqoWQ0GKmiKv0p0ouxKN6kL4WmFc01pnfZxtbBI58YXEugJXvMXqBuEOAvfAG3Jp3qPhZ64vT Mxyw8HrGyIIAC9fvxv9ZzX7kCmie2FgIcHYDOFNNUFZSLhS4fE7hRJwacFZpyQ7/PXoAr3A3VCJbg mK0txX+5A==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by merlin.infradead.org with esmtpsa (Exim 4.92.2 #3 (Red Hat Linux)) id 1iCkAF-0000Nf-M0; Tue, 24 Sep 2019 12:43:31 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 17485305E35; Tue, 24 Sep 2019 14:42:40 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id AD4FF20D83742; Tue, 24 Sep 2019 14:43:25 +0200 (CEST) Date: Tue, 24 Sep 2019 14:43:25 +0200 From: Peter Zijlstra To: Michal Hocko Subject: Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware Message-ID: <20190924124325.GQ2349@hirez.programming.kicks-ass.net> References: <20190923154852.GG2369@hirez.programming.kicks-ass.net> <20190923165235.GD17206@dhcp22.suse.cz> <20190923203410.GI2369@hirez.programming.kicks-ass.net> <20190924074751.GB23050@dhcp22.suse.cz> <20190924091714.GJ2369@hirez.programming.kicks-ass.net> <20190924105622.GH23050@dhcp22.suse.cz> <20190924112349.GJ2332@hirez.programming.kicks-ass.net> <20190924115401.GM23050@dhcp22.suse.cz> <20190924120943.GP2349@hirez.programming.kicks-ass.net> <20190924122500.GP23050@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190924122500.GP23050@dhcp22.suse.cz> User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: dalias@libc.org, linux-sh@vger.kernel.org, catalin.marinas@arm.com, dave.hansen@linux.intel.com, heiko.carstens@de.ibm.com, jiaxun.yang@flygoat.com, linux-mips@vger.kernel.org, mwb@linux.vnet.ibm.com, paulus@samba.org, hpa@zytor.com, sparclinux@vger.kernel.org, chenhc@lemote.com, will@kernel.org, cai@lca.pw, linux-s390@vger.kernel.org, ysato@users.sourceforge.jp, x86@kernel.org, Yunsheng Lin , rppt@linux.ibm.com, borntraeger@de.ibm.com, dledford@redhat.com, mingo@redhat.com, jeffrey.t.kirsher@intel.com, jhogan@kernel.org, mattst88@gmail.com, len.brown@intel.com, gor@linux.ibm.com, anshuman.khandual@arm.com, gregkh@linuxfoundation.org, bp@alien8.de, luto@kernel.org, tglx@linutronix.de, naveen.n.rao@linux.vnet.ibm.com, linux-arm-kernel@lists.infradead.org, rth@twiddle.net, axboe@kernel.dk, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, ralf@linux-mips.org, tbogendoerfer@suse.de, paul.burton@mips.com, linux-alpha@vger.kernel.org, rafael@kernel.org, ink@jurassic.park.msu.ru, akpm@linux-foundation.org, robin.murphy@arm.com, davem@davemloft.net Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Tue, Sep 24, 2019 at 02:25:00PM +0200, Michal Hocko wrote: > On Tue 24-09-19 14:09:43, Peter Zijlstra wrote: > > We can push back and say we don't respect the specification because it > > is batshit insane ;-) > > Here is my fingers crossed. > > [...] > > > Now granted; there's a number of virtual devices that really don't have > > a node affinity, but then, those are not hurt by forcing them onto a > > random node, they really don't do anything. Like: > > Do you really consider a random node a better fix than simply living > with a more robust NUMA_NO_NODE which tells the actual state? Page > allocator would effectivelly use the local node in that case. Any code > using the cpumask will know that any of the online cpus are usable. For the pmu devices? Yes, those 'devices' aren't actually used for anything other than sysfs entries. Nothing else uses the struct device. > Compare that to a wild guess that might be easily wrong and have subtle > side effects which are really hard to debug. You will only see a higher > utilization on a specific node. Good luck with a bug report like that. We'd have the FW_BUG in the dmesg, which should be a big fat clue. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware Date: Tue, 24 Sep 2019 14:43:25 +0200 Message-ID: <20190924124325.GQ2349@hirez.programming.kicks-ass.net> References: <20190923154852.GG2369@hirez.programming.kicks-ass.net> <20190923165235.GD17206@dhcp22.suse.cz> <20190923203410.GI2369@hirez.programming.kicks-ass.net> <20190924074751.GB23050@dhcp22.suse.cz> <20190924091714.GJ2369@hirez.programming.kicks-ass.net> <20190924105622.GH23050@dhcp22.suse.cz> <20190924112349.GJ2332@hirez.programming.kicks-ass.net> <20190924115401.GM23050@dhcp22.suse.cz> <20190924120943.GP2349@hirez.programming.kicks-ass.net> <20190924122500.GP23050@dhcp22.suse.cz> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=z5wfISW69eZ/kWXd4xS3/YcskS/mxFjheiW7ixIex14=; b=WIMYj2tRUrC7JYkCCQxCqzPmr eY7v/diobkQ+WLbrXSbzwyxW4iMZCZphUYFSPt9rrDdGl9ZKXo2i0OceglW9WDcIPsjHcxD15Qc2Y K9ozUDMls72WuTWCN/TorFuAf4A6PAQ5Xh0ACawwLZJ3mXrTTg1uJPW5mjf7w7vC5NgBQBysGTU3U np6ZtqoWQ0GKmiKv0p0ouxKN6kL4WmFc01pnfZxtbBI58YXEugJXvMXqBuEOAvfAG3Jp3qPhZ64vT Mxyw8HrGyIIAC9fvxv9ZzX7kCmie2FgIcHYDOFNNUFZSLhS4fE7hRJwacFZpyQ7/PXoAr3A3VCJbg Content-Disposition: inline In-Reply-To: <20190924122500.GP23050@dhcp22.suse.cz> Sender: linux-kernel-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Michal Hocko Cc: Yunsheng Lin , catalin.marinas@arm.com, will@kernel.org, mingo@redhat.com, bp@alien8.de, rth@twiddle.net, ink@jurassic.park.msu.ru, mattst88@gmail.com, benh@kernel.crashing.org, paulus@samba.org, mpe@ellerman.id.au, heiko.carstens@de.ibm.com, gor@linux.ibm.com, borntraeger@de.ibm.com, ysato@users.sourceforge.jp, dalias@libc.org, davem@davemloft.net, ralf@linux-mips.org, paul.burton@mips.com, jhogan@kernel.org, jiaxun.yang@flygoat.com, chenhc@lemote.com, akpm@linux-foundation.org, rppt@linux.ibm.com, anshuman.khandual@arm.com, tglx@linutronix.de, cai@lca.pw, robin.murphy@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, hpa@zytor.com, x86@kernel.org, dave.hansen@linux.intel.com, luto@kernel.org, len.brown@intel.com, axboe@kernel.dk On Tue, Sep 24, 2019 at 02:25:00PM +0200, Michal Hocko wrote: > On Tue 24-09-19 14:09:43, Peter Zijlstra wrote: > > We can push back and say we don't respect the specification because it > > is batshit insane ;-) > > Here is my fingers crossed. > > [...] > > > Now granted; there's a number of virtual devices that really don't have > > a node affinity, but then, those are not hurt by forcing them onto a > > random node, they really don't do anything. Like: > > Do you really consider a random node a better fix than simply living > with a more robust NUMA_NO_NODE which tells the actual state? Page > allocator would effectivelly use the local node in that case. Any code > using the cpumask will know that any of the online cpus are usable. For the pmu devices? Yes, those 'devices' aren't actually used for anything other than sysfs entries. Nothing else uses the struct device. > Compare that to a wild guess that might be easily wrong and have subtle > side effects which are really hard to debug. You will only see a higher > utilization on a specific node. Good luck with a bug report like that. We'd have the FW_BUG in the dmesg, which should be a big fat clue.