Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp4101398ybl; Mon, 27 Jan 2020 16:41:54 -0800 (PST) X-Google-Smtp-Source: APXvYqzTZQdhj6OYKdqMk3NuQYHc+Hgvuj4GWortWVM0WwN01B8uGTdkfMd8TfxHh/0V3LxDV6af X-Received: by 2002:a05:6830:10c4:: with SMTP id z4mr14851074oto.120.1580172113987; Mon, 27 Jan 2020 16:41:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580172113; cv=none; d=google.com; s=arc-20160816; b=jcXR9rp1rfzCkhLnTImnLNYHBWU1/6xAw7ydoH1EwiBMTDVnvRVxEW4aXiRv5MyKMG L7ryVxpICNezNbE4e4brMsmMQxBOj8d7CY9cXlE4XRTUkBRi06U+Gf1OjuqPKjmJqEfS mgBlUgT2A8QcJsaCK0JHI721Sx/IQ6sb5X8vgR6eBoJkjAuyg+midACV0Msy1AXXsGV2 +Z84ivMLhMWzP2W7rG2YBk9BcquI/vnZfb+nlndcIT8NNlMBf3F2blLYWIG8uVTnnvjO mjDA7wtZJnv85O9pSnD+Guyrn0arExNhU0DstUUvjnv/PmXBUvJhSolt5QhlqwAjWVZx u6oQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:reply-to:message-id :subject:cc:to:from:date; bh=0aCxZBiSaMQTx0hfZoLM7FxMKGyXBabUJ8fpuOdOkFI=; b=t1tXU5h44lFMBf/ww0xL31jXRc5guqOtGEAb6FuxnUrUrPgrK55DXyFNryNohsblah OTw76tmflvbzqaZ3VJ1t6oCWpgKsvTdbrgIpb2b73c6cD533d1YHt95iLP1JEHf2rEEn O3WyOdlcLmPtHduzLD24XU2Mf0ovalc/+eRpaDDsZQb1OCA9EL6U3OEg+0bf3agJy6xy mHU43adNHHelgXxY9Q7V61O/Ec/nCDnL8jVYCJw69sRAwW5BztNUqU9ar7fbsZol14I4 gkTsXf6bcunvnwIxl4cc1584WzGIwz5y067Pvk037FLwhrIKPts8UXrUodqQjydrbXjT +eIQ== 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=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 19si4297954oiq.128.2020.01.27.16.41.35; Mon, 27 Jan 2020 16:41:53 -0800 (PST) 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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726852AbgA1Ajb (ORCPT + 99 others); Mon, 27 Jan 2020 19:39:31 -0500 Received: from mga12.intel.com ([192.55.52.136]:7369 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726080AbgA1Ajb (ORCPT ); Mon, 27 Jan 2020 19:39:31 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jan 2020 16:39:30 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,371,1574150400"; d="scan'208";a="261265782" Received: from richard.sh.intel.com (HELO localhost) ([10.239.159.54]) by fmsmga002.fm.intel.com with ESMTP; 27 Jan 2020 16:39:29 -0800 Date: Tue, 28 Jan 2020 08:39:42 +0800 From: Wei Yang To: David Rientjes Cc: Wei Yang , akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/vmscan.c: only adjust related kswapd cpu affinity when online cpu Message-ID: <20200128003942.GC20624@richard> Reply-To: Wei Yang References: <20200126132052.11921-1-richardw.yang@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jan 26, 2020 at 02:44:31PM -0800, David Rientjes wrote: >On Sun, 26 Jan 2020, Wei Yang wrote: > >> When onlining a cpu, kswapd_cpu_online() is called to adjust kswapd cpu >> affinity. >> >> Current routine does like this: >> >> * Iterate all the numa node >> * Adjust cpu affinity when node has an online cpu >> >> Actually we could improve this by: >> >> * Just adjust the numa node to which current online cpu belongs >> >> Because we know which numa node the cpu belongs to and this cpu would >> not affect other node. >> > >Is there ever a situation where the cpu to be onlined would have appeared >in the cpumask of another node and so a different kswapd's cpumask would >now include an off-node cpu? No, I don't think so. Per my understanding, kswapd_cpu_online() will be invoked when a cpu is onlined. And the particular cpu belongs to a particular numa node. So it is not necessary to iterate on every nodes. And current code use cpumask_and_any() to do the check. If my understanding is correct, the check would return true if this node has any online cpu. This is likely to be true. This is why I want to make the logic clear. > >> Signed-off-by: Wei Yang >> --- >> mm/vmscan.c | 19 ++++++++++--------- >> 1 file changed, 10 insertions(+), 9 deletions(-) >> >> diff --git a/mm/vmscan.c b/mm/vmscan.c >> index 572fb17c6273..19c92d35045c 100644 >> --- a/mm/vmscan.c >> +++ b/mm/vmscan.c >> @@ -4049,18 +4049,19 @@ unsigned long shrink_all_memory(unsigned long nr_to_reclaim) >> restore their cpu bindings. */ >> static int kswapd_cpu_online(unsigned int cpu) >> { >> - int nid; >> + int nid = cpu_to_node(cpu); >> + pg_data_t *pgdat; >> + const struct cpumask *mask; >> >> - for_each_node_state(nid, N_MEMORY) { >> - pg_data_t *pgdat = NODE_DATA(nid); >> - const struct cpumask *mask; >> + if (!node_state(nid, N_MEMORY)) >> + return 0; >> >> - mask = cpumask_of_node(pgdat->node_id); >> + pgdat = NODE_DATA(nid); >> + mask = cpumask_of_node(nid); >> + >> + /* One of our CPUs online: restore mask */ >> + set_cpus_allowed_ptr(pgdat->kswapd, mask); >> >> - if (cpumask_any_and(cpu_online_mask, mask) < nr_cpu_ids) >> - /* One of our CPUs online: restore mask */ >> - set_cpus_allowed_ptr(pgdat->kswapd, mask); >> - } >> return 0; >> } >> >> -- >> 2.17.1 >> >> >> -- Wei Yang Help you, Help me