From: David Hildenbrand <email@example.com>
To: Minchan Kim <firstname.lastname@example.org>,
Andrew Morton <email@example.com>
Cc: linux-mm <firstname.lastname@example.org>,
email@example.com, firstname.lastname@example.org, email@example.com,
firstname.lastname@example.org, email@example.com, firstname.lastname@example.org,
Subject: Re: [PATCH v3 3/3] mm: fs: Invalidate BH LRU during page migration
Date: Fri, 12 Mar 2021 10:33:48 +0100 [thread overview]
Message-ID: <email@example.com> (raw)
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
David / dhildenb
next prev parent reply other threads:[~2021-03-12 9:34 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-10 16:14 [PATCH v3 1/3] mm: replace migrate_prep with lru_add_drain_all Minchan Kim
2021-03-10 16:14 ` [PATCH v3 2/3] mm: disable LRU pagevec during the migration temporarily Minchan Kim
2021-03-11 22:41 ` Chris Goldsworthy
2021-03-14 5:10 ` Chris Goldsworthy
2021-03-12 8:21 ` Michal Hocko
2021-03-12 9:00 ` David Hildenbrand
2021-03-18 0:13 ` Andrew Morton
2021-03-18 1:13 ` Minchan Kim
2021-03-18 8:09 ` Michal Hocko
2021-03-10 16:14 ` [PATCH v3 3/3] mm: fs: Invalidate BH LRU during page migration Minchan Kim
2021-03-12 9:03 ` David Hildenbrand
2021-03-12 9:33 ` David Hildenbrand [this message]
2021-03-12 17:17 ` Minchan Kim
2021-03-16 18:26 ` Minchan Kim
2021-03-17 11:18 ` David Hildenbrand
2021-03-17 2:37 ` [mm] 8fd8d23ab1: WARNING:at_fs/buffer.c:#__brelse kernel test robot
2021-03-17 16:29 ` Minchan Kim
2021-03-19 14:05 ` Oliver Sang
2021-03-19 16:47 ` Minchan Kim
2021-03-12 8:19 ` [PATCH v3 1/3] mm: replace migrate_prep with lru_add_drain_all Michal Hocko
2021-03-12 8:53 ` David Hildenbrand
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).