linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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



      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