Received: by 2002:a5d:9c59:0:0:0:0:0 with SMTP id 25csp181366iof; Mon, 6 Jun 2022 00:49:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy8dQJJO346Pv/i5ZTu7VNKfdNZAaiPGfX899nAxwdnarOz4VrRoIl0oRxjSIOABA9/emc5 X-Received: by 2002:a63:110:0:b0:3fd:3da3:8397 with SMTP id 16-20020a630110000000b003fd3da38397mr11822957pgb.461.1654501787260; Mon, 06 Jun 2022 00:49:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654501787; cv=none; d=google.com; s=arc-20160816; b=xXlOdhBCKoOtMUFS5gpIZUtJZzCsMrnISh7yBgJwDtYk38xr//NH7sjeWtZzAT+Aig yneWxTe0F5Q3hf6b+vKLdxyrPULCsAxny/DY/HVtiZhziNRsrB82y6EbIr3ci12JXBze iZJ6BPj9PqQyM+iDMwh8gUcKJHFHOg32wKjTQ+jpaHTD/XC01BBN1a6a4N691cMcIAER F+4Zt00bIKzuidVv2CnnEJmfxBD9EVWiqvLcE84AJ4RHUJCBdYIS6H6VjpGBt/lp0fyj gPyluoDw9oYY5nfIsls+5P0TSNrUXCOJIswMt1ePm1u/4ZDZoSRbUOJJIa62Yi3MILJM kv1g== 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 :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:dkim-signature; bh=VeBTnEzJAZ7BVeYzHFiItoM+9B+WSeMgEFR6iDFhIVM=; b=bx5nYWf8AkL7CvHcOdBM5hHLeyieHBp7toSTMUrSTwBQ5Amzx6DdNLux/irvDlOGJu rom2k1eeyNvmG07uFSrN+RamMVlFsjiEuyOQnmxRO40EnwmivEnbQ/A5hNEp5F7BRBB0 DlefjRGgeGDG8jbV7SXwczsWfTvQM20koase6acndQkcujzAbAqUZyRRkCgygBtAoeQK pLmHmFPNEP6yeb3rOdwufUPz42jQlMW9uu7WeSy+MeHk3BXBuxqHrv1iw1XPrgT22JNv QZs2PHLUR0DGty/mJ0qHEyHWze3VNUlxR7h1rC46LnOa7SaZKoVb6pPzKVUdNG53V4Yf Op5w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=W096bTZK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id o20-20020a635a14000000b003fa95b7538fsi7798692pgb.871.2022.06.06.00.49.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Jun 2022 00:49:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=W096bTZK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 489322B276; Mon, 6 Jun 2022 00:25:06 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230448AbiFFHYz (ORCPT + 99 others); Mon, 6 Jun 2022 03:24:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52052 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230381AbiFFHYx (ORCPT ); Mon, 6 Jun 2022 03:24:53 -0400 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 615F31AF16 for ; Mon, 6 Jun 2022 00:24:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1654500292; x=1686036292; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=xNNv8f5KLFlwE8E16qBiInBjz2utO9UckXry2wUB1oc=; b=W096bTZK6adSx4Fy1Zg0nkqhm1yjBOU76u90E+cYBep6CEhgFMWK9uZ1 EK1OEo1U/obOC+7X/CZJc3lZIYeUNcwKn24jqQKa7RtwThYmzA/ivq4VM DhD9sXlc7YpcbWOfl2cZMsP3yP1rC6P7lNG2SLtmsss19JRm7sR1HHY+H qRqmkloh1/2sZFSeBPp72GG/VkuYaTYzZZekIoHMdKY6DAaQll47IoHba nYxLG3Tbsg2O8Bqje+DtXx5ao9XtFcihmQOv2LCM2XKvISd1ivPi3RXaU kA7sZlwMjoKk41heCB9UOCAXmQo1ajJJXpkv3CJseujVrlp9VplEov97N g==; X-IronPort-AV: E=McAfee;i="6400,9594,10369"; a="275411503" X-IronPort-AV: E=Sophos;i="5.91,280,1647327600"; d="scan'208";a="275411503" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jun 2022 00:24:52 -0700 X-IronPort-AV: E=Sophos;i="5.91,280,1647327600"; d="scan'208";a="635461994" Received: from xingguom-mobl.ccr.corp.intel.com ([10.254.213.116]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jun 2022 00:24:43 -0700 Message-ID: <11f94e0c50f17f4a6a2f974cb69a1ae72853e2be.camel@intel.com> Subject: Re: [PATCH v5 9/9] mm/demotion: Update node_is_toptier to work with memory tiers From: Ying Huang To: Aneesh Kumar K V , linux-mm@kvack.org, akpm@linux-foundation.org Cc: Wei Xu , Greg Thelen , Yang Shi , Davidlohr Bueso , Tim C Chen , Brice Goglin , Michal Hocko , Linux Kernel Mailing List , Hesham Almatary , Dave Hansen , Jonathan Cameron , Alistair Popple , Dan Williams , Feng Tang , Jagdish Gediya , Baolin Wang , David Rientjes Date: Mon, 06 Jun 2022 15:24:38 +0800 In-Reply-To: References: <20220603134237.131362-1-aneesh.kumar@linux.ibm.com> <20220603134237.131362-10-aneesh.kumar@linux.ibm.com> <6e94b7e2a6192e4cacba1db3676b5b5cf9b98eac.camel@intel.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2022-06-06 at 09:22 +0530, Aneesh Kumar K V wrote: > On 6/6/22 8:41 AM, Ying Huang wrote: > > On Fri, 2022-06-03 at 19:12 +0530, Aneesh Kumar K.V wrote: > > > With memory tiers support we can have memory on NUMA nodes > > > in the top tier from which we want to avoid promotion tracking NUMA > > > faults. Update node_is_toptier to work with memory tiers. To > > > avoid taking locks, a nodemask is maintained for all demotion > > > targets. All NUMA nodes are by default top tier nodes and as > > > we add new lower memory tiers NUMA nodes get added to the > > > demotion targets thereby moving them out of the top tier. > > > > Check the usage of node_is_toptier(), > > > > - migrate_misplaced_page() > >    node_is_toptier() is used to check whether migration is a promotion. > > We can avoid to use it. Just compare the rank of the nodes. > > > > - change_pte_range() and change_huge_pmd() > >    node_is_toptier() is used to avoid scanning fast memory (DRAM) pages > > for promotion. So I think we should change the name to node_is_fast() > > as follows, > > > > static inline bool node_is_fast(int node) > > { > > return NODE_DATA(node)->mt_rank >= MEMORY_RANK_DRAM; > > } > > > > But that gives special meaning to MEMORY_RANK_DRAM. As detailed in other > patches, absolute value of rank doesn't carry any meaning. It is only > the relative value w.r.t other memory tiers that decide whether it is > fast or not. Agreed by default memory tiers get built with > MEMORY_RANK_DRAM. But userspace can change the rank value of 'memtier1' > Hence to determine a node is consisting of fast memory is essentially > figuring out whether node is the top most tier in memory hierarchy and > not just the memory tier rank value is >= MEMORY_RANK_DRAM? In a system with 3 tiers, HBM 0 DRAM 1 PMEM 2 In your implementation, only HBM will be considered fast. But what we need is to consider both HBM and DRAM fast. Because we use NUMA balancing to promote PMEM pages to DRAM. It's unnecessary to scan HBM and DRAM pages for that. And there're no requirements to promote DRAM pages to HBM with NUMA balancing. I can understand that the memory tiers are more dynamic now. For requirements of NUMA balancing, we need the lowest memory tier (rank) where there's at least one node with CPU. The nodes in it and the higher tiers will be considered fast. Best Regards, Huang, Ying