linux-kernel - Re: [PATCH v11 4/8] mm/demotion/dax/kmem: Set node's abstract distance to MEMTIER_ADISTANCE

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: <87h72wjv27.fsf@yhuang6-desk2.ccr.corp.intel.com>
Date:   Mon, 01 Aug 2022 15:13:04 +0800
From:   "Huang, Ying" <ying.huang@...el.com>
To:     Aneesh Kumar K V <aneesh.kumar@...ux.ibm.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
Subject: Re: [PATCH v11 4/8] mm/demotion/dax/kmem: Set node's abstract
 distance to MEMTIER_ADISTANCE_PMEM

Aneesh Kumar K V <aneesh.kumar@...ux.ibm.com> writes:

> On 8/1/22 12:07 PM, Huang, Ying wrote:
>> Aneesh Kumar K V <aneesh.kumar@...ux.ibm.com> writes:
>> 
>>> On 8/1/22 10:40 AM, Huang, Ying wrote:
>>>> Aneesh Kumar K V <aneesh.kumar@...ux.ibm.com> writes:
>>>>
>>>>> On 8/1/22 7:36 AM, Huang, Ying wrote:
>>>>>> "Aneesh Kumar K.V" <aneesh.kumar@...ux.ibm.com> writes:
>>>>>>
>>>>>>> "Huang, Ying" <ying.huang@...el.com> writes:
>>>>>>>
>>>>>>>> "Aneesh Kumar K.V" <aneesh.kumar@...ux.ibm.com> writes:
>
> ....
>
>>>>>
>>>>> With the module unload, it is kind of force removing the usage of the specific memtype.
>>>>> Considering module unload will remove the usage of specific memtype from other parts
>>>>> of the kernel and we already do all the required reset in memory hot unplug, do we
>>>>> need to do the clear_node_memory_type above? 
>>>>
>>>> Per my understanding, we need to call clear_node_memory_type() in
>>>> dev_dax_kmem_remove().  After that, we have nothing to do in
>>>> dax_kmem_exit().
>>>>
>>>
>>> Ok, I guess you are suggesting to do the clear_node_memory_type even if we fail the memory remove. 
>> 
>> Can we use node_memory_types[] to indicate whether a node is managed by
>> a driver?
>> 
>> Regardless being succeeded or failed, dev_dax_kmem_remove() will set
>> node_memory_types[] = NULL.  But until node is offlined, we will still
>> keep the node in the memory_dev_type (dax_pmem_type).
>> 
>> And we will prevent dax/kmem from unloading via try_module_get() and add
>> "struct module *" to struct memory_dev_type.
>> 
>
> Current dax/kmem driver is not holding any module reference and allows the module to be unloaded
> anytime. Even if the memory onlined by the driver fails to be unplugged. Addition of memory_dev_type
> as suggested by you will be different than that. Page demotion can continue to work without the
> support of dax_pmem_type as long as we keep the older demotion order. Any new demotion order
> rebuild will remove the the memory node which was not hotunplugged  from the demotion order. Isn't that
> a much simpler implementation? 

Per my understanding, unbinding/binding the dax/kmem driver means
changing the memory type of a memory device.  For example, unbinding
dax/kmem driver may mean changing the memory type from dax_pmem_type to
default_memory_type (or default_dram_type).  That appears strange.  But
if we force the NUMA node to be offlined for unbinding, we can avoid to
change the memory type to default_memory_type.

Best Regards,
Huang, Ying