From: David Hildenbrand <david@redhat.com>
To: Eric Ren <renzhengeek@gmail.com>
Cc: linux-mm@kvack.org
Subject: Re: Question about virtio_mm: why plug/unplug with 4MB granularity?
Date: Thu, 25 Nov 2021 12:37:58 +0100 [thread overview]
Message-ID: <ca201a3e-1c82-9db9-7bff-b772f8300267@redhat.com> (raw)
In-Reply-To: <7299f769-3dc8-1f77-c4f2-1e3dc7427689@gmail.com>
On 25.11.21 12:27, Eric Ren wrote:
> Hi David,
Hi Eric,
>
> As the subject, I'm wondering if we can make virtio_mm plug/unplug with
> futher more fine granularity like
>
> 2MB?
That's actually very high on my todo list. See "Hot(un)plug Granularity"
under:
https://virtio-mem.gitlab.io/developer-guide.html
>
>
> I gave it try as below, and it works.
>
> 1. Revert this patch: aac65321ba69("mm/memory_hotplug: simplify page
> onlining");
>
> 2. Tell mm hotplug core invoke online page callback with order 9 with
> changes as below;
>
>
> ```
>
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 5873563a3518..22a9636402b1 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -622,7 +622,9 @@ static int online_pages_range(unsigned long
> start_pfn, unsigned long nr_pages,
> * them as being online/belonging to this zone ("present").
> */
> for (pfn = start_pfn; pfn < end_pfn; pfn += 1ul << order) {
> - order = min(MAX_ORDER - 1, get_order(PFN_PHYS(end_pfn -
> pfn)));
> + /* 2MB callback */
> + order = min(MAX_ORDER - 2, get_order(PFN_PHYS(end_pfn -
> pfn)));
> /* __free_pages_core() wants pfns to be aligned to the
> order */
> ```
>
> 3. in virtio_mem driver, change subblock size to 2MB.
>
>
> Thought the hack testing works, I'm feeling not safe.
Yes, it's not safe in general when unplugging memory. When plugging
memory, some changes to virtio_mem_online_page_cb() are required. It has
to traverse all pageblocks part of the passed range -- so that avoids
the mm/memory_hotplug.c change above.
But for memory unplug, alloc_contig_range() and pageblock isolation
needs changes (below).
>
>
> Could you please help give some insights on these questions?
>
> 1. Is 4M a hard limitation?
No, the target is 2M. It will improve virtio-mem capability on
ZONE_NORMAL significantly.
>
> 2. What troubles we can foresee if using 2MB as granularity?
alloc_contig_range() needs to be taught to handle pageblock granularity
(2M) correctly. Otherwise unplug on ZONE_NORMAL will be mostly broken.
Fortunately, this is WIP, but still needs to fix some things:
https://lkml.kernel.org/r/20211115193725.737539-1-zi.yan@sent.com
--
Thanks,
David / dhildenb
prev parent reply other threads:[~2021-11-25 11:38 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-25 11:27 Eric Ren
2021-11-25 11:37 ` David Hildenbrand [this message]
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ca201a3e-1c82-9db9-7bff-b772f8300267@redhat.com \
--to=david@redhat.com \
--cc=linux-mm@kvack.org \
--cc=renzhengeek@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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