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 4EDE9C433F5 for ; Sun, 29 May 2022 04:31:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 592018D0003; Sun, 29 May 2022 00:31:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 53FB48D0001; Sun, 29 May 2022 00:31:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 406888D0003; Sun, 29 May 2022 00:31:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 30B1D8D0001 for ; Sun, 29 May 2022 00:31:45 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id E18B120943 for ; Sun, 29 May 2022 04:31:44 +0000 (UTC) X-FDA: 79517507328.10.CF88E4C Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by imf23.hostedemail.com (Postfix) with ESMTP id E1DB914004D for ; Sun, 29 May 2022 04:31:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1653798700; x=1685334700; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=t3c/Rw6oHrKkRAWVQS+d6BYwqueqvTGSN0tvGDscmAY=; b=NMomCbTEAyHNp9WlHb0O4e2jez2MwgV1H7hj1t2HpI5U79FaZgn4rgSi IqKJ+jb9JWVAe0dRlqT/p8gW8memC3dub9zLHNou8Bc4BYMbhOjIEeVWT aLlVgIJpqXcYNwKQf96WYpdUkbgUka/jQizIUwbB87Axl4iW+RrHhQYBQ +Hg8O6kTweM3dPLz9cyARYl87FyVuai0JG492HidSg6GxS3PcNLGndRFG vBdiQDX8llRKA/H5ZJPU8fP7ajS2pooPw5w5wEmVHVkBqy944hiorA53V miFwVT7YCcbzRzgz2xVr2wlH2jMocRDvidnnYBREDubz/kbDUE832KJbX g==; X-IronPort-AV: E=McAfee;i="6400,9594,10361"; a="274842642" X-IronPort-AV: E=Sophos;i="5.91,260,1647327600"; d="scan'208";a="274842642" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 May 2022 21:31:38 -0700 X-IronPort-AV: E=Sophos;i="5.91,260,1647327600"; d="scan'208";a="604627739" Received: from lli111-mobl.ccr.corp.intel.com ([10.254.214.246]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 May 2022 21:31:33 -0700 Message-ID: <1281d918c07b05ac82aee290018ad08d212e0aaa.camel@intel.com> Subject: Re: RFC: Memory Tiering Kernel Interfaces (v3) From: Ying Huang To: Wei Xu , Aneesh Kumar K V Cc: Andrew Morton , 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 , Linux MM , Jagdish Gediya , Baolin Wang , David Rientjes Date: Sun, 29 May 2022 12:31:30 +0800 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: E1DB914004D X-Stat-Signature: fq8gtfy6a5rsggputk7ksgyf1dtfctpi Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=NMomCbTE; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf23.hostedemail.com: domain of ying.huang@intel.com has no SPF policy when checking 192.55.52.115) smtp.mailfrom=ying.huang@intel.com X-Rspam-User: X-HE-Tag: 1653798676-246518 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 Fri, 2022-05-27 at 09:30 -0700, Wei Xu wrote: > On Fri, May 27, 2022 at 6:41 AM Aneesh Kumar K V > wrote: > > > > On 5/27/22 2:52 AM, Wei Xu wrote: > > > > >    The order of memory tiers is determined by their rank values, not by > > >    their memtier device names. > > > > > >    - /sys/devices/system/memtier/possible > > > > > >      Format: ordered list of "memtier(rank)" > > >      Example: 0(64), 1(128), 2(192) > > > > > >      Read-only. When read, list all available memory tiers and their > > >      associated ranks, ordered by the rank values (from the highest > > >       tier to the lowest tier). > > > > > > > Did we discuss the need for this? I haven't done this in the patch > > series I sent across. > > The "possible" file is only needed if we decide to hide the > directories of memtiers that have no nodes. We can remove this > interface and always show all memtier directories to keep things > simpler. When discussed offline, Tim Chen pointed out that with the proposed interface, it's unconvenient to know the position of a given memory tier in all memory tiers. We must sort "rank" of all memory tiers to know that. "possible" file can be used for that. Although "possible" file can be generated with a shell script, it's more convenient to show it directly. Another way to address the issue is to add memtierN/pos for each memory tier as suggested by Tim. It's readonly and will show position of "memtierN" in all memory tiers. It's even better to show the relative postion to the default memory tier (DRAM with CPU). That is, the position of DRAM memory tier is 0. Unlike memory tier device ID or rank, the position is relative and dynamic. Best Regards, Huang, Ying