linux-kernel - Re: RFC: Memory Tiering Kernel Interfaces (v3)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <21b95ac3-4b3c-3455-93c6-8257fcbff527@linux.ibm.com>
Date:   Wed, 8 Jun 2022 10:11:29 +0530
From:   Aneesh Kumar K V <aneesh.kumar@...ux.ibm.com>
To:     Tim Chen <tim.c.chen@...ux.intel.com>,
        Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        Ying Huang <ying.huang@...el.com>
Cc:     Wei Xu <weixugc@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Greg Thelen <gthelen@...gle.com>,
        Yang Shi <shy828301@...il.com>,
        Davidlohr Bueso <dave@...olabs.net>,
        Tim C Chen <tim.c.chen@...el.com>,
        Brice Goglin <brice.goglin@...il.com>,
        Michal Hocko <mhocko@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Hesham Almatary <hesham.almatary@...wei.com>,
        Dave Hansen <dave.hansen@...el.com>,
        Alistair Popple <apopple@...dia.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Feng Tang <feng.tang@...el.com>, Linux MM <linux-mm@...ck.org>,
        Jagdish Gediya <jvgediya@...ux.ibm.com>,
        Baolin Wang <baolin.wang@...ux.alibaba.com>,
        David Rientjes <rientjes@...gle.com>
Subject: Re: RFC: Memory Tiering Kernel Interfaces (v3)

On 6/8/22 12:55 AM, Tim Chen wrote:
> On Mon, 2022-05-30 at 13:50 +0100, Jonathan Cameron wrote:
>>
>>> 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.
>>
>>
> 
> You can argue that
> 
> $ cat /sys/devices/system/cpu/cpu1/topology/core_siblings
> f
> $ cat /sys/devices/system/cpu/cpu1/topology/core_siblings_list
> 0-3
> 
> provide exactly the same information and we should get rid of
> core_siblings_list.  I think core_siblings_list exists to make
> it easier for a human, so he/she doesn't have to parse the mask,
> or write a script to find out the ids of CPUs who are siblings.
> 
> I think in the same spirit, having an interface to allow a
> human to quickly see the hierachical relationship of tiers
> relative to each other is helpful.
> 

We can add that later if we find applications requiring this. I kind of 
have the feeling that we are adding too much based on possible ways 
memory tiers could be used in the future. For now we can look at doing 
bare minimum to address the current constraints and drive more user 
visible changes later based on application requirements.

-aneesh