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 1A5D5C43334 for ; Wed, 8 Jun 2022 16:08:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8205F6B0071; Wed, 8 Jun 2022 12:08:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7CF626B0072; Wed, 8 Jun 2022 12:08:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6BED16B0073; Wed, 8 Jun 2022 12:08:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 5E04F6B0071 for ; Wed, 8 Jun 2022 12:08:26 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 3703C612BD for ; Wed, 8 Jun 2022 16:08:26 +0000 (UTC) X-FDA: 79555551012.17.EC83A29 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by imf06.hostedemail.com (Postfix) with ESMTP id 31DE6180065 for ; Wed, 8 Jun 2022 16:08:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1654704503; x=1686240503; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=b0yvZkdbEo9Wm5Jp8QeqmDfGK82Rr8wPTjbjd78sR5M=; b=GTsyZ7IOfNuH/8hRFJzc1tE+jvy574JKlndrt3Ij8ED8xT6zL2x0PrSP fiI0MJlENTtyBb3cYvPRw3GaK7PUWFIDtiu0zFMUZvXdmIeoIhyLlfXip FX+ZNiSVB75nKtekk2HkvK/BKaGWtuukg7lZsFicCHNkg7xJ+rPMCJLxz fKS7kFlUuU0tinvOlt99ItOCssM6KOnUFnXZbHH2G678oxm5LomsiVQiv nQ7ogi55LqsW260LCe60uIz+yftkqqKkUe1F8KlwblgLSnVzqXtGZ06eg pyzXZE9meZVzJ7fX8kIXPBekQF/lmVRvBU2madto1sqQztlrK84VruTgs w==; X-IronPort-AV: E=McAfee;i="6400,9594,10372"; a="278119394" X-IronPort-AV: E=Sophos;i="5.91,286,1647327600"; d="scan'208";a="278119394" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jun 2022 09:06:11 -0700 X-IronPort-AV: E=Sophos;i="5.91,286,1647327600"; d="scan'208";a="615448127" Received: from schen9-mobl.amr.corp.intel.com (HELO majassow-mobl2.amr.corp.intel.com) ([10.209.124.119]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jun 2022 09:06:10 -0700 Message-ID: Subject: Re: [PATCH v5 2/9] mm/demotion: Expose per node memory tier to sysfs From: Tim Chen To: Aneesh Kumar K V , linux-mm@kvack.org, akpm@linux-foundation.org Cc: Wei Xu , Huang Ying , 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 09:06:09 -0700 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.34.4 (3.34.4-1.fc31) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=GTsyZ7IO; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf06.hostedemail.com: domain of tim.c.chen@linux.intel.com has no SPF policy when checking 134.134.136.65) smtp.mailfrom=tim.c.chen@linux.intel.com X-Stat-Signature: ojehsxw1tqnhxupfwijim7xj989k13te X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 31DE6180065 X-HE-Tag: 1654704502-643845 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. > I think we should have an efficient mapping from node to memtier from the get go. There are many easily envisioned scenarios where we need to map from node to memtier, which Ying pointed out. Tim