Received: by 2002:a5d:9c59:0:0:0:0:0 with SMTP id 25csp2270706iof; Wed, 8 Jun 2022 01:02:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwC21iVxPvEmDHhz4u7r3aeEa8SQ2h1bh5AnY7+bjNhdsw0N8Yk0pOuMVjTtrKGna4FcUVr X-Received: by 2002:a17:902:7d93:b0:14d:d401:f59b with SMTP id a19-20020a1709027d9300b0014dd401f59bmr33498590plm.14.1654675341232; Wed, 08 Jun 2022 01:02:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654675341; cv=none; d=google.com; s=arc-20160816; b=cPglVs4HPY5Bjnsg/ED8s43qiO1em68yUUsjP4dhlQ85A1gB3kzkMcYrQKlgUmqJ69 dIcicEAs+y9dKe0mG8M+k6S+yTk6jWWpHYECeAvzBRD3teZqQdwMGJvAUpFYJjg14fwQ LrlTKWHL6hCwQ9DisFDmLW695BLv2YW9S+G67rCPc7Lwp+ea9zJUom/TAgbF/dlngVhb i0MasWnxhoCwulNiKWx4MQXUDJP3JzMtOiuiAo0sgIIEHKXa1VNK7Vi/MvJ6S2S/Q4iu RA8Fta36eDJnCWeh1TV39hAGknyAF9o+Ccbz1C3E+8aIBwU4A42xt/pBcrSgvv9/P1aj bWBQ== 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=N7/a7RLBBvi6hSZ9D9Bo+Jlj2ggVxjkYKD6pSN1pLPQ=; b=XaX2T1xwpNhYVW79EdDnEAaPiLt3FKz/9Cs0jW92nQVrQZNcuyY1DnQEGK8+BO9UkB FMD9uD4BmZCEoZfdyPy4S12N0n/KgWcKCbdqwmvLEG3cOPLUjvXAqkcZZf3VA3BLSDSn 9vIz6z6KqdNtFR9nVtE1p/6P22dB9BpHoZRQH3DOo5Ei5vsT2YK9T8ZnsA2BBurY9sUG YzL8ZVyrSFrVQoBxAtX8VzhZkroYR5ELe0/q879l/VGu6E8JJXfza9D8bT6rJ+y4AQZK dnOX2SllazdfrkmXW3HVFEWfIJxkARRoSYWkXtPHBSwIt79WfzdBVF9SKcd64OYxkneS 9xBg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=fBC7l95K; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id jh2-20020a170903328200b00163e1591f90si26231983plb.24.2022.06.08.01.02.05; Wed, 08 Jun 2022 01:02:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=fBC7l95K; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241685AbiFHHMj (ORCPT + 99 others); Wed, 8 Jun 2022 03:12:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59684 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243146AbiFHGvO (ORCPT ); Wed, 8 Jun 2022 02:51:14 -0400 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D1E1517DDCC for ; Tue, 7 Jun 2022 23:42:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1654670562; x=1686206562; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=Jb5Q9Xorlzkgr5sm1kTa2c32QeDSwnsiMBz2O49CaLE=; b=fBC7l95KaVGahUWADJqLf71dXMxBk+1Tgolrdqq6VlV+/jie6oYVqrGp oZasi6YW6mnLy24NAhZQbjz4xUko1fWKXyAXz36uuduLbEm11txeS+DcX J1QrxJFjMzXUi95VdvKP7PyhOeS1B9Mx3q8Opm2AcOMnRXZhdkH7Vd98i a//HchoNXd2PGNcOUZYGVU2bG5ANv7HNvq5p3X3fxpDqfZPiz1rkgzF8r XsCT+RV6cqZbgwn2j3A7gC1g4nL+7IM1ZOeWplXCCFtXUj0LX1GU+Phii FIgxIf/3dWZIJAFH7hSSrTuOpQXhVK9iNYTk6A49d/s90nD/rMdwu7cck g==; X-IronPort-AV: E=McAfee;i="6400,9594,10371"; a="363136883" X-IronPort-AV: E=Sophos;i="5.91,285,1647327600"; d="scan'208";a="363136883" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga105.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-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham 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. 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 >