linux-kernel - Re: [PATCH v10 1/8] mm/demotion: Add support for explicit memory tiers

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: <9e9ba2e4-3a87-3a79-e336-8849dad4856a@linux.ibm.com>
Date:   Tue, 26 Jul 2022 17:29:56 +0530
From:   Aneesh Kumar K V <aneesh.kumar@...ux.ibm.com>
To:     "Huang, Ying" <ying.huang@...el.com>
Cc:     linux-mm@...ck.org, akpm@...ux-foundation.org,
        Wei Xu <weixugc@...gle.com>, Yang Shi <shy828301@...il.com>,
        Davidlohr Bueso <dave@...olabs.net>,
        Tim C Chen <tim.c.chen@...el.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>,
        Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        Alistair Popple <apopple@...dia.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Johannes Weiner <hannes@...xchg.org>, jvgediya.oss@...il.com,
        Jagdish Gediya <jvgediya@...ux.ibm.com>
Subject: Re: [PATCH v10 1/8] mm/demotion: Add support for explicit memory
 tiers


>> diff --git a/include/linux/node.h b/include/linux/node.h
>> index 40d641a8bfb0..a2a16d4104fd 100644
>> --- a/include/linux/node.h
>> +++ b/include/linux/node.h
>> @@ -92,6 +92,12 @@ struct node {
>>  	struct list_head cache_attrs;
>>  	struct device *cache_dev;
>>  #endif
>> +	/*
>> +	 * For memory devices, perf_level describes
>> +	 * the device performance and how it should be used
>> +	 * while building a memory hierarchy.
>> +	 */
>> +	int perf_level;
> 
> Think again, I found that "perf_level" may be not the best abstraction
> of the performance of memory devices.  In concept, it's an abstraction of the memory
> bandwidth.  But it will not reflect the memory latency.
> 
> Instead, the previous proposed "abstract_distance" is an abstraction of
> the memory latency.  Per my understanding, the memory latency has more
> direct influence on system performance.  And because the latency of the
> memory device will increase if the memory accessing throughput nears its
> max bandwidth, so the memory bandwidth can be reflected in the "abstract
> distance" too.  That is, the "abstract distance" is an abstraction of
> the memory latency under the expected memory accessing throughput.  The
> "offset" to the default "abstract distance" reflects the different
> expected memory accessing throughput.
> 
> So, I think we need some kind of abstraction of the memory latency
> instead of memory bandwidth, e.g., "abstract distance".
> 

I am reworking other parts of the patch set based on your feedback. This part
I guess we need to reach some consensus. 

IMHO perf_level (performance level) can indicate a combination of both latency
and bandwidth. It is an abstract concept that indicates the performance of the
device. As we learn more about which device attribute makes more impact in
defining hierarchy, performance level will give more weightage to that specific
attribute. It could be write latency or bandwidth. For me, distance has a direct
linkage to latency because that is how we define numa distance now. Adding
abstract to the name is not making it more abstract than perf_level. 

I am open to suggestions from others.  Wei Xu has also suggested perf_level name.
I can rename this to abstract_distance if that indicates the goal better.


-aneesh