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 DDCC8C433F5 for ; Mon, 30 May 2022 12:50:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 58B716B0071; Mon, 30 May 2022 08:50:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5375E6B0072; Mon, 30 May 2022 08:50:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 400C56B0073; Mon, 30 May 2022 08:50:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 2D5D16B0071 for ; Mon, 30 May 2022 08:50:54 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id F0BB721377 for ; Mon, 30 May 2022 12:50:53 +0000 (UTC) X-FDA: 79522393986.19.5D21187 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by imf04.hostedemail.com (Postfix) with ESMTP id 19F3740035 for ; Mon, 30 May 2022 12:50:30 +0000 (UTC) Received: from fraeml744-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4LBZtl1hd1z6H77v; Mon, 30 May 2022 20:47:27 +0800 (CST) Received: from lhreml710-chm.china.huawei.com (10.201.108.61) by fraeml744-chm.china.huawei.com (10.206.15.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Mon, 30 May 2022 14:50:46 +0200 Received: from localhost (10.81.211.14) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Mon, 30 May 2022 13:50:45 +0100 Date: Mon, 30 May 2022 13:50:43 +0100 From: Jonathan Cameron To: Ying Huang CC: Wei Xu , Aneesh Kumar K V , Andrew Morton , "Greg Thelen" , Yang Shi , "Davidlohr Bueso" , Tim C Chen , Brice Goglin , Michal Hocko , "Linux Kernel Mailing List" , Hesham Almatary , Dave Hansen , "Alistair Popple" , Dan Williams , "Feng Tang" , Linux MM , Jagdish Gediya , Baolin Wang , "David Rientjes" Subject: Re: RFC: Memory Tiering Kernel Interfaces (v3) Message-ID: <20220530135043.00001e88@Huawei.com> In-Reply-To: <1281d918c07b05ac82aee290018ad08d212e0aaa.camel@intel.com> References: <1281d918c07b05ac82aee290018ad08d212e0aaa.camel@intel.com> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.29; i686-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.81.211.14] X-ClientProxiedBy: lhreml732-chm.china.huawei.com (10.201.108.83) To lhreml710-chm.china.huawei.com (10.201.108.61) X-CFilter-Loop: Reflected X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 19F3740035 X-Stat-Signature: ag7736ptxr9ixpp3xug8k3dbphayba6x Authentication-Results: imf04.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf04.hostedemail.com: domain of jonathan.cameron@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=jonathan.cameron@huawei.com X-HE-Tag: 1653915030-544138 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 Sun, 29 May 2022 12:31:30 +0800 Ying Huang wrote: > 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: =20 > > >=20 > > > On 5/27/22 2:52 AM, Wei Xu wrote: > > > =20 > > > > =A0=A0=A0The order of memory tiers is determined by their rank valu= es, not by > > > > =A0=A0=A0their memtier device names. > > > >=20 > > > > =A0=A0=A0- /sys/devices/system/memtier/possible > > > >=20 > > > > =A0=A0=A0=A0=A0Format: ordered list of "memtier(rank)" > > > > =A0=A0=A0=A0=A0Example: 0(64), 1(128), 2(192) > > > >=20 > > > > =A0=A0=A0=A0=A0Read-only. When read, list all available memory tie= rs and their > > > > =A0=A0=A0=A0=A0associated ranks, ordered by the rank values (from t= he highest > > > > =A0=A0=A0=A0=A0=A0tier to the lowest tier). > > > > =20 > > >=20 > > > Did we discuss the need for this? I haven't done this in the patch > > > series I sent across. =20 > >=20 > > 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. =20 >=20 > 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. >=20 > 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. >=20 > Unlike memory tier device ID or rank, the position is relative and > dynamic. Hi, I'm unconvinced. This is better done with a shell script than by adding ABI we'll have to live with for ever.. I'm no good at shell scripting but this does the job=20 grep "" tier*/rank | sort -n -k 2 -t :=20 tier2/rank:50 tier0/rank:100 tier1/rank:200 tier3/rank:240 I'm sure someone more knowledgeable will do it in a simpler fashion still. Jonathan >=20 > Best Regards, > Huang, Ying >=20 >=20