linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: linux-kernel@vger.kernel.org
Cc: linux-mm@kvack.org, linux-s390@vger.kernel.org,
	virtualization@lists.linux.dev, linux-doc@vger.kernel.org,
	kvm@vger.kernel.org, "David Hildenbrand" <david@redhat.com>,
	"Heiko Carstens" <hca@linux.ibm.com>,
	"Vasily Gorbik" <gor@linux.ibm.com>,
	"Alexander Gordeev" <agordeev@linux.ibm.com>,
	"Christian Borntraeger" <borntraeger@linux.ibm.com>,
	"Sven Schnelle" <svens@linux.ibm.com>,
	"Thomas Huth" <thuth@redhat.com>,
	"Cornelia Huck" <cohuck@redhat.com>,
	"Janosch Frank" <frankja@linux.ibm.com>,
	"Claudio Imbrenda" <imbrenda@linux.ibm.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Jason Wang" <jasowang@redhat.com>,
	"Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
	"Eugenio Pérez" <eperezma@redhat.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Mario Casquero" <mcasquer@redhat.com>
Subject: [PATCH v2 7/7] s390/sparsemem: reduce section size to 128 MiB
Date: Mon, 14 Oct 2024 16:46:19 +0200	[thread overview]
Message-ID: <20241014144622.876731-8-david@redhat.com> (raw)
In-Reply-To: <20241014144622.876731-1-david@redhat.com>

Ever since commit 421c175c4d609 ("[S390] Add support for memory hot-add.")
we've been using a section size of 256 MiB on s390 and 32 MiB on s390.
Before that, we were using a section size of 32 MiB on both
architectures.

Likely the reason was that we'd expect a storage increment size of
256 MiB under z/VM back then. As we didn't support memory blocks spanning
multiple memory sections, we would have had to handle having multiple
memory blocks for a single storage increment, which complicates things.
Although that issue reappeared with even bigger storage increment sizes
later, nowadays we have memory blocks that can span multiple memory
sections and we avoid any such issue completely.

Now that we have a new mechanism to expose additional memory to a VM --
virtio-mem -- reduce the section size to 128 MiB to allow for more
flexibility and reduce the metadata overhead when dealing with hot(un)plug
granularity smaller than 256 MiB.

128 MiB has been used by x86-64 since the very beginning. arm64 with 4k
base pages switched to 128 MiB as well: it's just big enough on these
architectures to allows for using a huge page (2 MiB) in the vmemmap in
sane setups with sizeof(struct page) == 64 bytes and a huge page mapping
in the direct mapping, while still allowing for small hot(un)plug
granularity.

For s390, we could even switch to a 64 MiB section size, as our huge page
size is 1 MiB: but the smaller the section size, the more sections we'll
have to manage especially on bigger machines. Making it consistent with
x86-64 and arm64 feels like te right thing for now.

Note that the smallest memory hot(un)plug granularity is also limited by
the memory block size, determined by extracting the memory increment
size from SCLP. Under QEMU/KVM, implementing virtio-mem, we expose 0;
therefore, we'll end up with a memory block size of 128 MiB with a
128 MiB section size.

Tested-by: Mario Casquero <mcasquer@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
---
 arch/s390/include/asm/sparsemem.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/s390/include/asm/sparsemem.h b/arch/s390/include/asm/sparsemem.h
index c549893602ea..ff628c50afac 100644
--- a/arch/s390/include/asm/sparsemem.h
+++ b/arch/s390/include/asm/sparsemem.h
@@ -2,7 +2,7 @@
 #ifndef _ASM_S390_SPARSEMEM_H
 #define _ASM_S390_SPARSEMEM_H
 
-#define SECTION_SIZE_BITS	28
+#define SECTION_SIZE_BITS	27
 #define MAX_PHYSMEM_BITS	CONFIG_MAX_PHYSMEM_BITS
 
 #endif /* _ASM_S390_SPARSEMEM_H */
-- 
2.46.1



  parent reply	other threads:[~2024-10-14 14:47 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-14 14:46 [PATCH v2 0/7] virtio-mem: s390 support David Hildenbrand
2024-10-14 14:46 ` [PATCH v2 1/7] s390/kdump: implement is_kdump_kernel() David Hildenbrand
2024-10-14 18:20   ` Heiko Carstens
2024-10-14 19:26     ` David Hildenbrand
2024-10-15  8:30       ` Heiko Carstens
2024-10-15  8:41         ` David Hildenbrand
2024-10-15  8:53           ` David Hildenbrand
2024-10-15  8:56             ` David Hildenbrand
2024-10-15 10:08           ` Heiko Carstens
2024-10-15 10:40             ` David Hildenbrand
2024-10-16 13:35               ` Alexander Egorenkov
2024-10-16 15:47                 ` David Hildenbrand
2024-10-16 15:54                   ` David Hildenbrand
2024-10-21 12:46                   ` Alexander Egorenkov
2024-10-21 14:45                     ` David Hildenbrand
2024-10-23  7:42                       ` Heiko Carstens
2024-10-23  7:45                         ` David Hildenbrand
2024-10-23 11:17                       ` Alexander Egorenkov
2024-10-14 14:46 ` [PATCH v2 2/7] Documentation: s390-diag.rst: make diag500 a generic KVM hypercall David Hildenbrand
2024-10-14 18:04   ` Heiko Carstens
2024-10-14 19:35     ` David Hildenbrand
2024-10-15  8:12       ` Heiko Carstens
2024-10-15  8:16         ` David Hildenbrand
2024-10-15  8:21           ` Heiko Carstens
2024-10-15  8:32             ` David Hildenbrand
2024-10-15  8:46               ` Heiko Carstens
2024-10-15  8:48                 ` David Hildenbrand
2024-10-14 14:46 ` [PATCH v2 3/7] Documentation: s390-diag.rst: document diag500(STORAGE LIMIT) subfunction David Hildenbrand
2024-10-14 14:46 ` [PATCH v2 4/7] s390/physmem_info: query diag500(STORAGE LIMIT) to support QEMU/KVM memory devices David Hildenbrand
2024-10-14 18:43   ` Heiko Carstens
2024-10-14 19:42     ` David Hildenbrand
2024-10-15 15:01     ` Eric Farman
2024-10-15 15:20       ` Heiko Carstens
2024-10-25 10:52         ` David Hildenbrand
2024-10-16 10:37       ` Halil Pasic
2024-10-17  7:36   ` Alexander Gordeev
2024-10-17  8:19     ` David Hildenbrand
2024-10-17  9:53       ` Alexander Gordeev
2024-10-17 10:00         ` David Hildenbrand
2024-10-17 12:07           ` David Hildenbrand
2024-10-17 14:32             ` Alexander Gordeev
2024-10-17 14:36               ` David Hildenbrand
2024-10-30 14:30   ` Alexander Gordeev
2024-10-30 14:33     ` Alexander Gordeev
2024-10-14 14:46 ` [PATCH v2 5/7] virtio-mem: s390 support David Hildenbrand
2024-10-14 18:48   ` Heiko Carstens
2024-10-14 19:16     ` David Hildenbrand
2024-10-15  8:37       ` Heiko Carstens
2024-10-21  6:33         ` Christian Borntraeger
2024-10-21 12:19           ` David Hildenbrand
2024-10-14 14:46 ` [PATCH v2 6/7] lib/Kconfig.debug: default STRICT_DEVMEM to "y" on s390 David Hildenbrand
2024-10-14 18:53   ` Heiko Carstens
2024-10-14 14:46 ` David Hildenbrand [this message]
2024-10-14 17:53   ` [PATCH v2 7/7] s390/sparsemem: reduce section size to 128 MiB Heiko Carstens
2024-10-14 19:47     ` David Hildenbrand
2024-10-14 18:56 ` [PATCH v2 0/7] virtio-mem: s390 support Heiko Carstens
2024-10-14 19:17   ` David Hildenbrand
2024-10-15  7:57   ` Claudio Imbrenda
2024-10-25 10:54     ` David Hildenbrand

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=20241014144622.876731-8-david@redhat.com \
    --to=david@redhat.com \
    --cc=agordeev@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=borntraeger@linux.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=corbet@lwn.net \
    --cc=eperezma@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=jasowang@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mcasquer@redhat.com \
    --cc=mst@redhat.com \
    --cc=svens@linux.ibm.com \
    --cc=thuth@redhat.com \
    --cc=virtualization@lists.linux.dev \
    --cc=xuanzhuo@linux.alibaba.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;
as well as URLs for NNTP newsgroup(s).