RE: Re: RE(2): FW: [LSF/MM/BPF TOPIC] SMDK inspired MM changes for CXL

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>On Fri, Mar 24, 2023 at 02:55:02PM +0000, Matthew Wilcox wrote:
>> No, that's not true.  You can allocate kernel memory from ZONE_MOVABLE.
>> You have to be careful when you do that, but eg filesystems put symlinks
>> and directories in ZONE_MOVABLE, and zswap allocates memory from
>> ZONE_MOVABLE.  Of course, then you have to be careful that the kernel
>> doesn't try to move it while you're accessing it.  That's the tradeoff.
>
>I want to talk a little bit about what it would take to use MOVABLE
>allocations for slab.
>
>Initially, one might presume that it is impossible to have slab use a
>movable allocation.  Usually, we need a relatively complex mechanism of
>reference counting where one takes a reference on the page, uses it,
>then puts the reference.  Then migration can check the page reference
>and if it's unused, it knows it's safe to migrate (much handwaving here,
>of course it's more complex).
>
>The general case of kmalloc slabs cannot use MOVABLE allocations.
>The API has no concept of "this pointer is temporarily not in use",
>so we can never migrate any slab which has allocated objects.
>
>But for slab caches, individual objects may have access rules which allow
>them to be moved.  For example, we might be able to migrate every dentry
>in a slab, then RCU-free the slab.  Similarly for radix_tree_nodes.
>
>There was some work along these lines a few years ago:
>https://lore.kernel.org/all/20190603042637.2018-16-tobin@xxxxxxxxxx/
>
>There are various practical problems with that patchset, but they can
>be overcome with sufficient work.  The question is: Why do we need to do
>this work?  What is the high-level motivation to make slab caches movable?


Thank you for sharing us the case.
We studied your sentences and the patchset. Let me summarize our understanding.
A kernel context is migratable at certain in case the reference count of a page is traceable and it is 0.

As I answered previously, our intention is the attribute of CXL DRAM page can be movable as well as unmovable.
A memory allocator context should be able to determine it.



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux