Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp3660330pxu; Sun, 11 Oct 2020 19:11:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxIrcq71qRVRtUCgOEE5P5isqJ5OMerOSb85yfOsVAAmPknBEtOtZ5ONa8k+Y7oD6Y/BNGU X-Received: by 2002:aa7:cf99:: with SMTP id z25mr11717173edx.139.1602468680839; Sun, 11 Oct 2020 19:11:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602468680; cv=none; d=google.com; s=arc-20160816; b=OeJyl17czy98cA6bYqWhWxQffvrRz31waGWuNym+0oBm1e8G/JkYG6BqxiAXjGxj+3 y9A+L2HVRI0fKUyXfvtjcQqDgv4/Zax2JpiTuFh5kfXLLzsQS78dRPBhlKBoPylrpiCR K6OADZEnplc6Fya+wPu3MfG90K1N/4l13m2iTGwxPU8pCanUmqkhG12lccYtVihhYL5U DzSgMCqgRKO4feRU0uuhE52QLct1e8GZsiexz38xGbupafsvddYviv1xjqO48Q5Sm8IA 1cWzq0F1oI8w+u48buWAkaBOZg5dmzqs1qTtkMD94IlTOqN+SJk59xerFHxyrUePTNSH X9MA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=5+CpqGtio1NVIa/h7Hhc9FMurrjkTK9GDxqfOkT1B6I=; b=pJ9EVIgEtb9x7XwrWzLDO44/6MIND+z8d6Qp15a3m1mIyIN/ZngnE2XldZqahlLSnT NSDXOP1snSjIOqc0MrAWZUKEul7VCx49/yiimc2VCcVArfAPnDpheoNIMUDk0mirmIM+ MR5PIDAtSl701XWMHCC8Jpk8JaeBm15FTWyQFDbHMv4VjHcC+5eA87xyNRDPu/Js40Mf eU3oT9p/5UNlf9iyVw8FflaPJEnkFWcrGSp58MtGlqlVqAttTKwno9sVDhZqNpaEcbz2 mqfwEiXy4y55ktf7i3xoNQvAvgFJ6/StDV1gxOjB1iKtxC3IrXjMO9Hg9FKRrWMnXpAu bIJw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=ycxvxyjE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j5si10809504edc.5.2020.10.11.19.10.57; Sun, 11 Oct 2020 19:11:20 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=ycxvxyjE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728817AbgJKTSF (ORCPT + 99 others); Sun, 11 Oct 2020 15:18:05 -0400 Received: from mail.kernel.org ([198.145.29.99]:52868 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726130AbgJKTSF (ORCPT ); Sun, 11 Oct 2020 15:18:05 -0400 Received: from kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com (unknown [163.114.132.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CEBD62078A; Sun, 11 Oct 2020 19:18:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1602443885; bh=HhlBchMur5+dR0BQIrVbePlgVQWliYk8BEnEPi2xzLA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ycxvxyjEAlRr3NUMTzWuXph28DNOB/LCA9i+XOyWvL/n4gP6ZkXh1QPXUOqKpJmwZ wccrPrD1m18L0j6kWuwNCaDU1FlpwIxdi/NOZWXmBQ+DEzMiy8DXf1UGHMFf6CjBmG tN3/PCiMcj7H+mZvlrq2D0JKUWp73syzncXMyeHQ= Date: Sun, 11 Oct 2020 12:18:03 -0700 From: Jakub Kicinski To: Xianting Tian Cc: , , Subject: Re: [PATCH] net: Avoid allocing memory on memoryless numa node Message-ID: <20201011121803.2c003c7e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> In-Reply-To: <20201011041140.8945-1-tian.xianting@h3c.com> References: <20201011041140.8945-1-tian.xianting@h3c.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 11 Oct 2020 12:11:40 +0800 Xianting Tian wrote: > In architecture like powerpc, we can have cpus without any local memory > attached to it. In such cases the node does not have real memory. > > Use local_memory_node(), which is guaranteed to have memory. > local_memory_node is a noop in other architectures that does not support > memoryless nodes. > > Signed-off-by: Xianting Tian > --- > net/core/dev.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/net/core/dev.c b/net/core/dev.c > index 266073e30..dcb4533ef 100644 > --- a/net/core/dev.c > +++ b/net/core/dev.c > @@ -2590,7 +2590,7 @@ static struct xps_map *expand_xps_map(struct xps_map *map, int attr_index, > new_map = kzalloc(XPS_MAP_SIZE(alloc_len), GFP_KERNEL); > else > new_map = kzalloc_node(XPS_MAP_SIZE(alloc_len), GFP_KERNEL, > - cpu_to_node(attr_index)); > + local_memory_node(cpu_to_node(attr_index))); > if (!new_map) > return NULL; > Are we going to patch all kmalloc_node() callers now to apply local_memory_node()? Can't the allocator take care of this?