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.3 required=3.0 tests=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 4243DC3402F for ; Tue, 18 Feb 2020 00:24:43 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E94472072C for ; Tue, 18 Feb 2020 00:24:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E94472072C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 484806B0003; Mon, 17 Feb 2020 19:24:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 434336B0006; Mon, 17 Feb 2020 19:24:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 34B2A6B0007; Mon, 17 Feb 2020 19:24:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0065.hostedemail.com [216.40.44.65]) by kanga.kvack.org (Postfix) with ESMTP id 18DAD6B0003 for ; Mon, 17 Feb 2020 19:24:42 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id C9005824805A for ; Tue, 18 Feb 2020 00:24:41 +0000 (UTC) X-FDA: 76501351962.04.drink38_460114b4f0e0b X-HE-Tag: drink38_460114b4f0e0b X-Filterd-Recvd-Size: 4241 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by imf49.hostedemail.com (Postfix) with ESMTP for ; Tue, 18 Feb 2020 00:24:40 +0000 (UTC) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Feb 2020 16:24:38 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,454,1574150400"; d="scan'208";a="433927310" Received: from richard.sh.intel.com (HELO localhost) ([10.239.159.54]) by fmsmga005.fm.intel.com with ESMTP; 17 Feb 2020 16:24:37 -0800 Date: Tue, 18 Feb 2020 08:24:56 +0800 From: Wei Yang To: Michal Hocko Cc: Wei Yang , akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, rientjes@google.com Subject: Re: [PATCH v2] mm/vmscan.c: only adjust related kswapd cpu affinity when online cpu Message-ID: <20200218002456.GA16623@richard> Reply-To: Wei Yang References: <20200214073320.28735-1-richardw.yang@linux.intel.com> <20200214085113.GP31689@dhcp22.suse.cz> <20200215003753.GA32682@richard> <20200217093124.GH31531@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200217093124.GH31531@dhcp22.suse.cz> User-Agent: Mutt/1.9.4 (2018-02-28) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Feb 17, 2020 at 10:31:24AM +0100, Michal Hocko wrote: >On Sat 15-02-20 08:37:53, Wei Yang wrote: >> On Fri, Feb 14, 2020 at 09:51:13AM +0100, Michal Hocko wrote: >> >On Fri 14-02-20 15:33:20, Wei Yang wrote: >> >> When onlining a cpu, kswapd_cpu_online() is called to adjust kswapd cpu >> >> affinity. >> >> >> >> Current routine does like this: >> >> >> >> a) Iterate all the numa node >> >> b) Adjust cpu affinity when node has an online cpu >> >> >> >> For a) this is not necessary, since the particular online cpu belongs to >> >> a particular numa node. So it is not necessary to iterate on every nodes >> >> on the system. This new onlined cpu just affect kswapd cpu affinity of >> >> this particular node. >> >> >> >> For b) several cpumask operation is used to check whether the node has >> >> an online CPU. Since at this point we are sure one of our CPU onlined, >> >> we can set the cpu affinity directly to current cpumask_of_node(). >> >> >> >> This patch simplifies the logic by set cpu affinity of the affected >> >> kswapd. >> > >> >How have you tested this patch? >> > >> >> I online one cpu and confirm the "cpu" is the one we just onlined. >> >> If my understanding is correct, this is the expected behavior. >> >> >Also this is an old code and quite convoluted but does it still work as >> >inteded? I mean, I do not see any cpu offline callback to reduce the >> >cpu mask as all the CPUs for the given node go offline? Wouldn't the >> >> You are right, I didn't see the counterpart for cpu offline. This is the >> question I want to ask. Seems we didn't handle it at the very beginning. >> >> >scheduler simply go and fallback to no affinity if that happens? >> >In other words what is the value of kswapd_cpu_online in the first >> >place? >> >> Some cases may this function be useful. >> >> If we have a memory node which doesn't have any online cpu, the default >> cpumask is not set. After one of the cpu online, we want to change cpu >> affinity. >> >> Or we want to add more cpu to the system, we could allow kswapd use more cpu >> resources. Otherwise, kswapd would be limited to those original cpus. > >OK, so the usecase is when a NUMA node gains a new CPU which wasn't >there at the time when the node got onlined. Is this a scenario we >really do care about? While not completely impossible I haven't seen >a system which would allow such a runtime configurability. Maybe it >would be simply easier to drop the callback for now until we have a real >world usecase to support it and have it documented. I am fine with this suggestion. Let me prepare v3. >-- >Michal Hocko >SUSE Labs -- Wei Yang Help you, Help me