Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp1233551rwe; Thu, 25 Aug 2022 19:18:36 -0700 (PDT) X-Google-Smtp-Source: AA6agR6W84qCLspDhqcNP6bu+Jg9j5G/vkcTpwy/loDjCNeo4FtzWRhqH5gsTXN5FVbdyi0L/rmo X-Received: by 2002:a17:907:eaa:b0:73d:9d0a:702f with SMTP id ho42-20020a1709070eaa00b0073d9d0a702fmr4167938ejc.713.1661480316235; Thu, 25 Aug 2022 19:18:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661480316; cv=none; d=google.com; s=arc-20160816; b=sGSU/U2X5qcJv/sbZn+6lZ2Eiq6bVGxbk5Kuv7MiyltByZxWWipH3DYahrRr1p9uea S7h3epyG51Dk39BQ235QdXDIqwP1uMO5FGfMmBGFuCZCR0SlblbVBRR61mXJ+uiPhedz AL4JMOmqh9yVgrdDbhTHXGdHW5hquyjlVtty8Aa5vvsqZ/d/UtxDz6OZi7ALRmz2rxB8 Kcb2uI7DWNsqaM4qJbNx9GP1oVNxLZxMzW6KsVj8cIIbvggbtMgwYJJMPoipN9EI3wvF /pgmx5pPvLSH6BATqsBmU6LcSzl66VfGSDpy1IBMboftGzWljXHk6Yay2Hn/Stpi+I1h usRA== 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:message-id:in-reply-to:date:references:subject:cc:to :from:dkim-signature; bh=yA94+1lfaXQdCovnLYumDHbqrKRYlU6B2AxBIWNPEzg=; b=cJYabG9wV30Zv3mgt5LT2fOD9ItWCkarj72kQpsEA/lR82OEUn66jRQWv3s4wjC/7O vIJISCNzR9QPWZFHRJpk5XvznEMau7E7JbWTBDWu8duyrEQ2GSCUVBt2ewBvBNNYcIc0 C+6jAueYCjLBQ48II4QWAN52YP8jVbj2Rc/THKx5XislV3RmqoZa/x8+FC5JcrJgHsy4 VkEzDQSmRudFXXGQ7OQ+zTdJxkRCLvyNh3nYNLnzQpcapaHgo+0E1CxxWQ2EYtslk3eV ue+swai/t+PNlBSlIxCECix3XMroVLgXSy6hKG8Cllb33XMkp96+mf0U3fXhOOVpd9XJ KwFA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="l5x/wlNX"; 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 ne28-20020a1709077b9c00b0073d888f8c4fsi535830ejc.236.2022.08.25.19.18.10; Thu, 25 Aug 2022 19:18:36 -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="l5x/wlNX"; 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 S244623AbiHZBuy (ORCPT + 99 others); Thu, 25 Aug 2022 21:50:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60894 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229845AbiHZBuw (ORCPT ); Thu, 25 Aug 2022 21:50:52 -0400 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5E4596E896 for ; Thu, 25 Aug 2022 18:50:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1661478651; x=1693014651; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version:content-transfer-encoding; bh=A+vo5oKdJvtFxj1nipyEpEz7lA9nkfXY7dHnH/JK1uc=; b=l5x/wlNXzRZBMMQjtTF5CFaIgK/Eo7zGYf+uMO6LJ7dGzlhW0IGOlcNI rMpatYa3AEeefOjRh2zMAaRs57ax7vOSonmp4THTmKwQ2Lwvguy3a0uOP cY5ZhgzVMlrTSZECd4TSGiDbE8W9LKzmiyDTQK0HgeLh+msYdXjIsOcPJ seGl9xoZ4h715EL8KAo3CXLf+MMqT2qWcGkWfu+2FFD2NnDqgsbuPnoEh gFn+oQ64nsR/GCcWC8wTVDqidLjaV+blwk9/a+mhOYoX2LY1xevw4vXCy 9hBW06pY7bAbPybmIZOLA9xcJmTy75s2mlbWr/dWCeFfpxVP73XYtnIJa g==; X-IronPort-AV: E=McAfee;i="6500,9779,10450"; a="293140433" X-IronPort-AV: E=Sophos;i="5.93,264,1654585200"; d="scan'208";a="293140433" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Aug 2022 18:50:51 -0700 X-IronPort-AV: E=Sophos;i="5.93,264,1654585200"; d="scan'208";a="643487574" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Aug 2022 18:50:46 -0700 From: "Huang, Ying" To: "Aneesh Kumar K.V" Cc: linux-mm@kvack.org, akpm@linux-foundation.org, Wei Xu , Yang Shi , Davidlohr Bueso , Tim C Chen , Michal Hocko , Linux Kernel Mailing List , Hesham Almatary , Dave Hansen , Jonathan Cameron , Alistair Popple , Dan Williams , Johannes Weiner , jvgediya.oss@gmail.com, Bharata B Rao Subject: Re: [RFC PATCH 1/2] mm/demotion: Expose memory type details via sysfs References: <20220825092325.381517-1-aneesh.kumar@linux.ibm.com> Date: Fri, 26 Aug 2022 09:50:43 +0800 In-Reply-To: <20220825092325.381517-1-aneesh.kumar@linux.ibm.com> (Aneesh Kumar K. V.'s message of "Thu, 25 Aug 2022 14:53:24 +0530") Message-ID: <877d2v3h8s.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.4 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 "Aneesh Kumar K.V" writes: > This patch adds /sys/devices/virtual/memtier/ where all memory tier relat= ed > details can be found. All allocated memory types will be listed there as > /sys/devices/virtual/memtier/memtypeN/ Another choice is to make memory types and memory tiers system devices. That is, /sys/devices/system/memory_type/memory_typeN /sys/devices/system/memory_tier/memory_tierN That looks more natural to me. Because we already have "node" and "memory" devices there. Why don't you put memory types and memory tiers there? And, I think we shouldn't put "memory_type" in the "memory_tier" directory. "memory_type" isn't a part of "memory_tier". > The nodes which are part of a specific memory type can be listed via > /sys/devices/system/memtier/memtypeN/nodes. How about create links to /sys/devices/system/node/nodeN in "memory_type". But I'm OK to have "nodes" file too. > The adistance value of a specific memory type can be listed via > /sys/devices/system/memtier/memtypeN/adistance. > > A directory listing looks like: > :/sys/devices/virtual/memtier# tree memtype1 > memtype1 > =E2=94=9C=E2=94=80=E2=94=80 adistance Why not just use "abstract_distance"? This is user space interface, it's better to be intuitive. > =E2=94=9C=E2=94=80=E2=94=80 nodes > =E2=94=9C=E2=94=80=E2=94=80 subsystem -> ../../../../bus/memtier > =E2=94=94=E2=94=80=E2=94=80 uevent > > Since we will be using struct device to expose details via sysfs, drop st= ruct > kref and use struct device for refcounting the memtype. > Best Regards, Huang, Ying