Re: RFC: Memory Tiering Kernel Interfaces (v3)

From: Aneesh Kumar K V
Date: Wed Jun 08 2022 - 02:00:58 EST

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