archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <>
To: Anshuman Khandual <>,
	Heiko Carstens <>
Cc:,,,,, Vasily Gorbik <>,
	Jonathan Cameron <>
Subject: Re: [RFC V2 3/3] s390/mm: Define arch_get_mappable_range()
Date: Tue, 8 Dec 2020 09:38:13 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

>> Both changes only make sense with an in-tree user. I'm planning on using
>> this functionality in virtio-mem code. I can pickup your patches, drop
>> the superfluous checks, and use it from virtio-mem code. Makese sense
>> (BTW, looks like we'll see aarch64 support for virtio-mem soon)?
> I have not been following virtio-mem closely. But is there something pending
> on arm64 platform which prevents virtio-mem enablement ?

Regarding enablement, I expect things to be working out of the box
mostly. Jonathan is currently doing some testing and wants to send a
simple unlock patch once done. [1]

Now, there are some things to improve in the future. virtio-mem
adds/removes individual Linux memory blocks and logically plugs/unplugs
MAX_ORDER - 1/pageblock_order pages inside Linux memory blocks.

1. memblock

On arm64 and powerpc, we create/delete memblocks when adding/removing
memory, which is suboptimal (and the code is quite fragile as we don't
handle errors ...). Hotplugged memory never has holes, so we can tweak
relevant code to not check via the memblock api.

For example, pfn_valid() only has to check for memblock_is_map_memory()
in case of !early_section() - otherwise it can just fallback to our
generic pfn_valid() function.

2. MAX_ORDER - 1 / pageblock_order

With 64k base pages, virtio-mem can only logically plug/unplug in 512MB
granularity, which is sub-optimal and inflexible. 4/2MB would be much
better - however this would require always using 2MB THP on arm64 (IIRC
via "cont" bits). Luckily, only some distributions use 64k base pages as
default nowadays ... :)

3. Section size

virtio-mem benefits from small section sizes. Currently, we have 1G.
With 4k base pages we could easily reduce it to something what x86 has
(128 MB) - and I remember discussions regarding that already in other
(IIRC NVDIMM / DIMM) context. Again, with 64k base pages we cannot go
below 512 MB right now.



David / dhildenb

  reply	other threads:[~2020-12-08  8:38 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-30  3:29 [RFC V2 0/3] mm/hotplug: Pre-validate the address range with platform Anshuman Khandual
2020-11-30  3:29 ` [RFC V2 1/3] mm/hotplug: Prevalidate the address range being added " Anshuman Khandual
2020-12-02  9:20   ` David Hildenbrand
2020-12-02 12:15     ` Anshuman Khandual
2020-11-30  3:29 ` [RFC V2 2/3] arm64/mm: Define arch_get_mappable_range() Anshuman Khandual
2020-12-02  9:26   ` David Hildenbrand
2020-12-02 12:17     ` Anshuman Khandual
2020-11-30  3:29 ` [RFC V2 3/3] s390/mm: " Anshuman Khandual
2020-12-02 20:32   ` Heiko Carstens
2020-12-03  0:33     ` Anshuman Khandual
2020-12-03 11:51       ` Heiko Carstens
2020-12-03 12:01         ` David Hildenbrand
2020-12-07  4:38           ` Anshuman Khandual
2020-12-07  9:03             ` David Hildenbrand
2020-12-08  5:32               ` Anshuman Khandual
2020-12-08  8:38                 ` David Hildenbrand [this message]
2020-12-02  6:44 ` [RFC V2 0/3] mm/hotplug: Pre-validate the address range with platform Anshuman Khandual
2020-12-02 20:35 ` Heiko Carstens
2020-12-03  0:12   ` Anshuman Khandual

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:

* 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).