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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id EACC0C433FE for ; Mon, 30 May 2022 12:50:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236195AbiE3Muw convert rfc822-to-8bit (ORCPT ); Mon, 30 May 2022 08:50:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39360 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232828AbiE3Muu (ORCPT ); Mon, 30 May 2022 08:50:50 -0400 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5B1B262CEA for ; Mon, 30 May 2022 05:50:49 -0700 (PDT) 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: 8BIT 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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: > > > > > > 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. 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 grep "" tier*/rank | sort -n -k 2 -t : 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 > > Best Regards, > Huang, Ying > >