Received: by 2002:a5d:9c59:0:0:0:0:0 with SMTP id 25csp2672285iof; Wed, 8 Jun 2022 09:37:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJypt4FfKaYVmsnCorka+oK6kvJRSeyjzoPPvPOY4beujbVKbP1CFyuHusxzR4cBRJKIt3fC X-Received: by 2002:a17:903:110e:b0:167:8847:5d9d with SMTP id n14-20020a170903110e00b0016788475d9dmr13002891plh.3.1654706228354; Wed, 08 Jun 2022 09:37:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654706228; cv=none; d=google.com; s=arc-20160816; b=oA2SH4rYqMLcyCKEBQ+nbypaFR9DJEyzAIv4A2i2XCUskuiMDyScA6RByRxq9i2naq c8MURrLcsutfaXG8TJKZbwiMEQxnJkcwzKO5c78mhCOgnB1fprSP6pPGVLgosmvG8L+2 U5lTou8Iysz5KpHFZ0sXa1N8LStUYXuiSW6C44A20HmPy+r6dRxKVTEzrvp2LAe8LGrP XDHFVm2g1LU3jPWA9QX+Fur+xG6c7weXHWQkLLvb1AYTEnYFkWtswWTRtk/ZoTafYZFC Z6zy/gW1XHtwiZAfhKWLo7MBoODMwpSrfh6yewoqC+24gt1/Seqi79DZqXtvzKg7PmFL fkTg== 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=WinxuV0qCdCbPXJ8P0hPKTH42NEudVaTls/SgJkXMnA=; b=1ADVc74d4tmZLV3ZTXmG5PTr4f5e3B9u3JqP7zfa2GcqbQa+xbSTDFUovEq8t1B0Dg daj1uObrJcV7YVlWiA6dHInd5vfiN/hGwBneQAOjYnfVtijPV3ZaRINmJuc3vp6DuG3H 8tMhV14kp4jmiXSYgVNe84qQREhK+jXLbggJU01FkXVni2x5u+bwY0TLiiKgExTB+/P6 fJ46sCnftIM37S1Wp2QezL+OAu+x451HPYx86VlayKrR0Nj8Ky08UUuxKsOTqmr5id+P zUneRnZ+8MXDIOMCJe7BCD+X2valUeDEtyrG5amSpGnwMHpXAp/BQZUyjne66G0kYP4P nscA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=lzn246qV; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 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. [23.128.96.19]) by mx.google.com with ESMTPS id bg13-20020a056a02010d00b003fdf4a14a22si7882744pgb.51.2022.06.08.09.37.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jun 2022 09:37:08 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=lzn246qV; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 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 D743A1F7023; Wed, 8 Jun 2022 09:09:43 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244972AbiFHQJa (ORCPT + 99 others); Wed, 8 Jun 2022 12:09:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51988 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244768AbiFHQJ2 (ORCPT ); Wed, 8 Jun 2022 12:09:28 -0400 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 120F627C for ; Wed, 8 Jun 2022 09:09:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1654704567; x=1686240567; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=b0yvZkdbEo9Wm5Jp8QeqmDfGK82Rr8wPTjbjd78sR5M=; b=lzn246qV+QjxlZyuZORNLNOdSv2i3CynCBLDHLcxP1nzvOYrjPSwSmPx QqpHgp1N10trraTIu+qN0QZkaza6UkxJ25mlBQqzKKi58Xoa2bcKiRrTx YmgRfBMfEvS08IIYeSIyYOAsjColPC1OTWB8V9nTJEI0S5YPNpiJV+mdq Il5gUkhUi7yh9eoATKOgO4hhQGM5ZsjX3MixWdFaLuLnQpiJJdS2tzXF9 rUx8wtfL2rMF6IK7ZOrcIRjRU6ICeOA3bIEyRhhWdK04dfv0fpkB8kmiO kYRm5W2gN9GojKg/Cb5biq0vFUd5rc0WNM/9Zv2MOqYRAOQRnjYRxnoZu A==; X-IronPort-AV: E=McAfee;i="6400,9594,10372"; a="274474137" X-IronPort-AV: E=Sophos;i="5.91,286,1647327600"; d="scan'208";a="274474137" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jun 2022 09:06:12 -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 X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 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