lkml.org 
[lkml]   [2021]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v3 3/3] mm: fs: Invalidate BH LRU during page migration
Date
On 12.03.21 10:03, David Hildenbrand wrote:
> On 10.03.21 17:14, Minchan Kim wrote:
>> ffer_head LRU caches will be pinned and thus cannot be migrated.
>> This can prevent CMA allocations from succeeding, which are often used
>> on platforms with co-processors (such as a DSP) that can only use
>> physically contiguous memory. It can also prevent memory
>> hot-unplugging from succeeding, which involves migrating at least
>> MIN_MEMORY_BLOCK_SIZE bytes of memory, which ranges from 8 MiB to 1
>> GiB based on the architecture in use.
>
> Actually, it's memory_block_size_bytes(), which can be even bigger
> (IIRC, 128MiB..2 GiB on x86-64) that fails to get offlined. But that
> will prevent bigger granularity (e.g., a whole DIMM) from getting unplugged.
>
>>
>> Correspondingly, invalidate the BH LRU caches before a migration
>> starts and stop any buffer_head from being cached in the LRU caches,
>> until migration has finished.
>
> Sounds sane to me.
>

Diving a bit into the code, I am wondering:


a) Are these buffer head pages marked as movable?

IOW, are they either PageLRU() or __PageMovable()?


b) How do these pages end up on ZONE_MOVABLE or MIGRATE_CMA?

I assume these pages come via
alloc_page_buffers()->alloc_buffer_head()->kmem_cache_zalloc(GFP_NOFS |
__GFP_ACCOUNT)



--
Thanks,

David / dhildenb

\
 
 \ /
  Last update: 2021-03-12 10:34    [W:0.108 / U:0.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site