Messages in this thread | | | Subject | Re: [PATCH v3 3/3] mm: fs: Invalidate BH LRU during page migration | From | David Hildenbrand <> | Date | Wed, 17 Mar 2021 12:18:07 +0100 |
| |
On 16.03.21 19:26, Minchan Kim wrote: > On Fri, Mar 12, 2021 at 09:17:23AM -0800, Minchan Kim wrote: >> On Fri, Mar 12, 2021 at 10:33:48AM +0100, David Hildenbrand wrote: >>> 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) >>> >> >> It's indirect it was not clear >> >> try_to_release_page >> try_to_free_buffers >> buffer_busy >> failed >> >> Yeah, comment is misleading. This one would be better. >> >> /* >> * the refcount of buffer_head in bh_lru prevents dropping the >> * attached page(i.e., try_to_free_buffers) so it could cause >> * failing page migrationn. >> * Skip putting upcoming bh into bh_lru until migration is done. >> */ >
Thanks, that makes more sense to me now :)
> Hi Andrew, > > Could you fold this comment fix patch? If you prefer formal patch, > let me know. I will resend it. > > Thank you. > > From 0774f21e2dc8220fc2be80c25f711cb061363519 Mon Sep 17 00:00:00 2001 > From: Minchan Kim <minchan@kernel.org> > Date: Fri, 12 Mar 2021 09:17:34 -0800 > Subject: [PATCH] comment fix > > Signed-off-by: Minchan Kim <minchan@kernel.org> > --- > fs/buffer.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/fs/buffer.c b/fs/buffer.c > index ca9dd736bcb8..8602dcbe0327 100644 > --- a/fs/buffer.c > +++ b/fs/buffer.c > @@ -1265,8 +1265,9 @@ static void bh_lru_install(struct buffer_head *bh) > > check_irqs_on(); > /* > - * buffer_head in bh_lru could increase refcount of the page > - * until it will be invalidated. It causes page migraion failure. > + * the refcount of buffer_head in bh_lru prevents dropping the > + * attached page(i.e., try_to_free_buffers) so it could cause > + * failing page migratoin.
s/migratoin/migration/
> * Skip putting upcoming bh into bh_lru until migration is done. > */ > if (lru_cache_disabled()) >
Acked-by: David Hildenbrand <david@redhat.com>
-- Thanks,
David / dhildenb
| |