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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 C65FDC41604 for ; Wed, 7 Oct 2020 18:08:16 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 35BCF21707 for ; Wed, 7 Oct 2020 18:08:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 35BCF21707 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 648AD6B0068; Wed, 7 Oct 2020 14:08:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5F8946B006C; Wed, 7 Oct 2020 14:08:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 50EB78E0001; Wed, 7 Oct 2020 14:08:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0133.hostedemail.com [216.40.44.133]) by kanga.kvack.org (Postfix) with ESMTP id 224AB6B0068 for ; Wed, 7 Oct 2020 14:08:15 -0400 (EDT) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id A2F058249980 for ; Wed, 7 Oct 2020 18:08:14 +0000 (UTC) X-FDA: 77345913708.15.brake84_2d13df1271d1 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin15.hostedemail.com (Postfix) with ESMTP id 83B8B1814B0C7 for ; Wed, 7 Oct 2020 18:08:14 +0000 (UTC) X-HE-Tag: brake84_2d13df1271d1 X-Filterd-Recvd-Size: 2565 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf31.hostedemail.com (Postfix) with ESMTP for ; Wed, 7 Oct 2020 18:08:13 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id A84E7AF9C; Wed, 7 Oct 2020 18:08:11 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 07 Oct 2020 20:08:10 +0200 From: osalvador@suse.de To: Dave Hansen Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, yang.shi@linux.alibaba.com, rientjes@google.com, ying.huang@intel.com, dan.j.williams@intel.com, david@redhat.com Subject: Re: [RFC][PATCH 3/9] mm/migrate: update migration order during on hotplug events In-Reply-To: <20201007161741.DDC85648@viggo.jf.intel.com> References: <20201007161736.ACC6E387@viggo.jf.intel.com> <20201007161741.DDC85648@viggo.jf.intel.com> User-Agent: Roundcube Webmail Message-ID: <8acf3637996d5c72709a3143f41165f8@suse.de> X-Sender: osalvador@suse.de 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 2020-10-07 18:17, Dave Hansen wrote: > From: Dave Hansen > > Reclaim-based migration is attempting to optimize data placement in > memory based on the system topology. If the system changes, so must > the migration ordering. > > The implementation here is pretty simple and entirely unoptimized. On > any memory or CPU hotplug events, assume that a node was added or > removed and recalculate all migration targets. This ensures that the > node_demotion[] array is always ready to be used in case the new > reclaim mode is enabled. > > This recalculation is far from optimal, most glaringly that it does > not even attempt to figure out if nodes are actually coming or going. > But, given the expected paucity of hotplug events, this should be > fine. Hi Dave, I am still going through all the details, but just wanted to comment early on this one. Could not you hook into __try_online_node/try_offline_node? In there we check whether a node should be brought up or removed due to lack of cpus and memory. That is being checked during hot-remove operations. We also have node_states_check_changes_{offline,online} and their pair node_states_{set,clear}_node, that checks during online/offline stages which states should be removed from the node, but that is only wrt. memory (I guess we would only be interested in N_MEMORY). Thanks