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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6CF6AC433EF for ; Wed, 8 Jun 2022 06:42:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B4DDD6B0071; Wed, 8 Jun 2022 02:42:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AD6EA6B0072; Wed, 8 Jun 2022 02:42:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 99DE76B0073; Wed, 8 Jun 2022 02:42:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 87EAB6B0071 for ; Wed, 8 Jun 2022 02:42:47 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 4E2DD20F8C for ; Wed, 8 Jun 2022 06:42:47 +0000 (UTC) X-FDA: 79554125574.30.2ABECD8 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by imf27.hostedemail.com (Postfix) with ESMTP id C75E740067 for ; Wed, 8 Jun 2022 06:42:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1654670564; x=1686206564; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=Jb5Q9Xorlzkgr5sm1kTa2c32QeDSwnsiMBz2O49CaLE=; b=m/3PkB89a/79aZuiULpN/Rxex4lctpGUM5igyjkai9jUrZnogfPCsy29 vHYq0lHHCJcl4b2X+7GusaCVDuTtR2Z5xcRO5+BpyYeAcxLlAbFcEiEhs zF3d6CEqIuxmKCgiIUNLPtJTKEmgjrENM5fYFuIWIcEDPVkOEF0o+Payi mnxCiNP2A3E/ClZKslIKC4EQY2fkxs2pCzgwxMJAYVVqFDakzJgQJN9pP bU71SvCOjnM634HwihiXzVFaUlxNKVvj3+XOQ/f2iFd39hiY4cJUrKB5y OE7GjNEXRWSWQyD9hMv6xwZ/2Y9JDHxvO2XeYNoY1XLVESeax9/LZQVhn A==; X-IronPort-AV: E=McAfee;i="6400,9594,10371"; a="257235847" X-IronPort-AV: E=Sophos;i="5.91,285,1647327600"; d="scan'208";a="257235847" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jun 2022 23:42:41 -0700 X-IronPort-AV: E=Sophos;i="5.91,285,1647327600"; d="scan'208";a="636616169" Received: from xding11-mobl.ccr.corp.intel.com ([10.254.214.239]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jun 2022 23:42:36 -0700 Message-ID: <052e3ba49bf815393ca4b51650134faee0d70feb.camel@intel.com> Subject: Re: [PATCH v5 2/9] mm/demotion: Expose per node memory tier to sysfs From: Ying Huang To: Aneesh Kumar K V , Tim Chen , 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: Wed, 08 Jun 2022 14:42:33 +0800 In-Reply-To: <626023e8-8443-619e-18ee-a758c37fcec2@linux.ibm.com> References: <20220603134237.131362-1-aneesh.kumar@linux.ibm.com> <20220603134237.131362-3-aneesh.kumar@linux.ibm.com> <626023e8-8443-619e-18ee-a758c37fcec2@linux.ibm.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: C75E740067 X-Stat-Signature: mf59ncpy6888bxmnctr3dxuqcg4m81qw X-Rspam-User: Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="m/3PkB89"; spf=none (imf27.hostedemail.com: domain of ying.huang@intel.com has no SPF policy when checking 192.55.52.151) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspamd-Server: rspam08 X-HE-Tag: 1654670564-192219 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 Wed, 2022-06-08 at 10:25 +0530, Aneesh Kumar K V wrote: > On 6/8/22 1:45 AM, Tim Chen wrote: > > On Fri, 2022-06-03 at 19:12 +0530, Aneesh Kumar K.V wrote: > > > > > >    > > > > > > > > > > > > +static struct memory_tier *__node_get_memory_tier(int node) > > > +{ > > > + struct memory_tier *memtier; > > > + > > > + list_for_each_entry(memtier, &memory_tiers, list) { > > > > We could need to map node to mem_tier quite often, if we need > > to account memory usage at tier level. It will be more efficient > > to have a pointer from node (pgdat) to memtier rather > > than doing a search through the list. > > > > > > That is something I was actively trying to avoid. Currently all struct > memory_tier references are with memory_tier_lock mutex held. That > simplify the locking and reference counting. > > As of now we are able to implement all the required interfaces without > pgdat having pointers to struct memory_tier. We can update pgdat with > memtier details when we are implementing changes requiring those. We > could keep additional memtier->dev reference to make sure memory tiers > are not destroyed while other part of the kernel is referencing the > same. But IMHO such changes should wait till we have users for the same. No. We need a convenient way to access memory tier information from inside the kernel. For example, from nid to memory tier rank, this is needed by migrate_misplaced_page() to do statistics too, iterate all nodes of a memory tier, etc. And, "allowed" field of struct demotion_nodes (introduced in [7/9] is per-memory tier instead of per-node. Please move it to struct memory_tier. And we just need a convenient way to access it. All these are not complex, unless you insist to use memory_tier_lock and device liftcycle to manage this in-kernel data structure. Best Regards, Huang, Ying > > > + if (node_isset(node, memtier->nodelist)) > > > + return memtier; > > > + } > > > + return NULL; > > > +} > > > + > > > > > > > Tim > > > > -aneesh >