Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp2375862ybh; Mon, 16 Mar 2020 01:56:07 -0700 (PDT) X-Google-Smtp-Source: ADFU+vs5yhuWWnH4W5s59h070XqfHCXsu9Rlk99cmIB9d6zyW+N06pxCE7r5oYEC9csddfQ2sTce X-Received: by 2002:a05:6808:90f:: with SMTP id w15mr16944055oih.0.1584348967698; Mon, 16 Mar 2020 01:56:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584348967; cv=none; d=google.com; s=arc-20160816; b=JFXtvH1QySCcZRROvQe3C6+LcfYCSvjZfxSupYFfAfXs0eTinrrcgHNOghjXqtLppm JkpSevSBx3ySOgTEgLdOUuvUrJYUm/Zbmo9F4+w0Kc34JXxaH0nl8h8aImlqHBfkRJr/ AnjcQoMfqrkfK1SJ7G0Ph2MMBttCzbFBWrt/kd1/Tuqgdw5JnMSkK2Yq6YvodQhZBPvD zhYd2wo8LuqsT+AXO25wPet6BONByQhk/sfrIia7Gyt5DT/06yYiSHPJ9+D7hOHBzDw1 zB0Zwo4at/9dc+FNp62swMjj6Ay2i5otzqYzDhc0mBsvJ55mozVCvP9EIpxTIAqCCp1j wodg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=oYVrvr0SPfoysj/NNmvUSSHpDs57n+aIQag0hdxed9Q=; b=L37AfoByiq2slpZEDY3fpw+L6WPF3hDrnsbT0rmcV6m7q47i6l8kwMckQ7WuM66TuA COZ1vB4iMoZsmmafhdrVG6M6I4hanTzXBunLMv4iRlS4kaDLjN3ypyO5WPUZYP968Kk9 5NFLYOcPsysN+WJi4Rf2jQtsYvEfiVehdcVA25joolnvUI4EZ7z+qgm7PSF34IGtv5tx GbxXjNwfYVSblYkEsixvAbTdfn/4PSzENHg+sh4HD3t+tprEa2c09VBpeYaDg7qPOkCZ CAn02YEsDzyFkzgHJaQvt0EGa1BU3MM517EUfxQLUrNPt2D4PT/EUF/kM/phWjuPZMIZ 11tw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f9si10193959oti.44.2020.03.16.01.55.54; Mon, 16 Mar 2020 01:56:07 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730271AbgCPIya (ORCPT + 99 others); Mon, 16 Mar 2020 04:54:30 -0400 Received: from mail-wm1-f66.google.com ([209.85.128.66]:54092 "EHLO mail-wm1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730131AbgCPIya (ORCPT ); Mon, 16 Mar 2020 04:54:30 -0400 Received: by mail-wm1-f66.google.com with SMTP id 25so16657445wmk.3 for ; Mon, 16 Mar 2020 01:54:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=oYVrvr0SPfoysj/NNmvUSSHpDs57n+aIQag0hdxed9Q=; b=bDnW7ZtF7HesZgM+hfU10AFngBAyRtXXp+/zvT2q+SsyDj/nBJeo6YjHh6cXu87Rf4 QTKYpyH61XPKRzyqR1uMfV9d+NchTZkhu2xYY++llavLTjnX0DABK6QqmwgygjL0BV/t S5S3ghlNY4RYC6Zj+ZuPdaJDMnSzDeWm5UdDZQWccfnmvXXi3ZsVYGYBHe/i6AXydlPI 6E1iXLS1rCdbFgodm5cQfI8l3h2KIKZkB1evFo680wTgDo/xBxtFFUqP1TsjV5sImiz1 Lxg1E87sgKFfHMmq+UBtgfX9yP9S88bGCgpnhdxGLVQeaLkroQqMePAQC2OS82ViOkfv X6rA== X-Gm-Message-State: ANhLgQ2v7QFxgOzuzawpMdKpL6QvJJz6wVQrBA4kjE1cDSwRRyhD6x9z qworOkXSPGzH6xRvhZGpHQw= X-Received: by 2002:a7b:c92a:: with SMTP id h10mr26017913wml.26.1584348868140; Mon, 16 Mar 2020 01:54:28 -0700 (PDT) Received: from localhost (ip-37-188-254-25.eurotel.cz. [37.188.254.25]) by smtp.gmail.com with ESMTPSA id o3sm31430395wme.36.2020.03.16.01.54.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Mar 2020 01:54:27 -0700 (PDT) Date: Mon, 16 Mar 2020 09:54:25 +0100 From: Michal Hocko To: Christopher Lameter Cc: Srikar Dronamraju , Andrew Morton , Michael Ellerman , linuxppc-dev@lists.ozlabs.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Mel Gorman , Vlastimil Babka , "Kirill A. Shutemov" , Linus Torvalds Subject: Re: [PATCH 3/3] mm/page_alloc: Keep memoryless cpuless node 0 offline Message-ID: <20200316085425.GB11482@dhcp22.suse.cz> References: <20200311110237.5731-1-srikar@linux.vnet.ibm.com> <20200311110237.5731-4-srikar@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun 15-03-20 14:20:05, Cristopher Lameter wrote: > On Wed, 11 Mar 2020, Srikar Dronamraju wrote: > > > Currently Linux kernel with CONFIG_NUMA on a system with multiple > > possible nodes, marks node 0 as online at boot. However in practice, > > there are systems which have node 0 as memoryless and cpuless. > > Would it not be better and simpler to require that node 0 always has > memory (and processors)? A mininum operational set? I do not think you can simply ignore the reality. I cannot say that I am a fan of memoryless/cpuless numa configurations but they are a sad reality of different LPAR configurations. We have to deal with them. Besides that I do not really see any strong technical arguments to lack a support for those crippled configurations. We do have zonelists that allow to do reasonable decisions on memoryless nodes. So no, I do not think that this is a viable approach. > We can dynamically number the nodes right? So just make sure that the > firmware properly creates memory on node 0? Are you suggesting that the OS would renumber NUMA nodes coming from FW just to satisfy node 0 existence? If yes then I believe this is really a bad idea because it would make HW/LPAR configuration matching to the resulting memory layout really hard to follow. -- Michal Hocko SUSE Labs