Message ID | 20240910191541.2179655-6-david@redhat.com (mailing list archive) |
---|---|
State | New |
Headers | show
Return-Path: <owner-linux-mm@kvack.org> X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D3CA7EDE9AD for <linux-mm@archiver.kernel.org>; Tue, 10 Sep 2024 19:16:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 706188D00AA; Tue, 10 Sep 2024 15:16:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6B4FC8D0002; Tue, 10 Sep 2024 15:16:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 57CE88D00AA; Tue, 10 Sep 2024 15:16:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 3AD2F8D0002 for <linux-mm@kvack.org>; Tue, 10 Sep 2024 15:16:32 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id B48F91A09B9 for <linux-mm@kvack.org>; Tue, 10 Sep 2024 19:16:31 +0000 (UTC) X-FDA: 82549784982.23.E130E2B Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf30.hostedemail.com (Postfix) with ESMTP id F283180015 for <linux-mm@kvack.org>; Tue, 10 Sep 2024 19:16:29 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=ZWNM2C8T; spf=pass (imf30.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725995762; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=xMATIjJHQHWxMji5r7WdDXGhstKkdxXCo0yMMstlfH8=; b=T/5jI8MG1dV1kaU4AOFQfj7k2JJpuvdlSrV9vIwVTCw6RY1tbtYSv4O4iZt2o1xqiBO8ia 8EKRabyA9dA9NmTpSYPoZF4D4bU6d6WWD56MUT7seZnoOyUAlB33XUAbjcBaTK00SUMXhF h5O/32QNOcstfUmc2W5dkWGrJ2RN78A= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=ZWNM2C8T; spf=pass (imf30.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725995762; a=rsa-sha256; cv=none; b=P6QnzCKx1Ij1SiFjDjNyl/47sdlCjrNfdwbhu6nSg8oV3tnV0UBLheH18svjlWQg6sKkJT aBKpGV5JoMF8X8I0UuBmRteiLO1PvJxggR4MvFlbBDEvldoKWmNQwHWonRftFVWcH/bnei UO1hv7WVUmwpohrOyzqPTbtrKaTWrqI= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1725995789; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xMATIjJHQHWxMji5r7WdDXGhstKkdxXCo0yMMstlfH8=; b=ZWNM2C8TqQNfWEiN6cAHxi5RXzN0wAzkFUXVU8r4X1nfww6FCKYaqC3a5klH0YZBmKEMXr oFl+uurE40hGGzoy3U37iQTf/MDnNnmdBlP7hCMU1Kw0Ujg+rF61LMjiXlU67k3ot/RExz NHmqwX1RWVmZIs/CzMkl4EdD2mO385M= Received: from mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-232-WbUGol_bMq2IBJu7l5Sszw-1; Tue, 10 Sep 2024 15:16:26 -0400 X-MC-Unique: WbUGol_bMq2IBJu7l5Sszw-1 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 2C2851955BC1; Tue, 10 Sep 2024 19:16:24 +0000 (UTC) Received: from t14s.fritz.box (unknown [10.22.17.222]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id DF81B30001A1; Tue, 10 Sep 2024 19:16:17 +0000 (UTC) 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, 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>, =?utf-8?q?Eugenio_P=C3=A9rez?= <eperezma@redhat.com>, Andrew Morton <akpm@linux-foundation.org> Subject: [PATCH v1 5/5] s390/sparsemem: reduce section size to 128 MiB Date: Tue, 10 Sep 2024 21:15:39 +0200 Message-ID: <20240910191541.2179655-6-david@redhat.com> In-Reply-To: <20240910191541.2179655-1-david@redhat.com> References: <20240910191541.2179655-1-david@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Rspam-User: X-Stat-Signature: idcdazj98d8zagh44y6xgcsrczfmaxtx X-Rspamd-Queue-Id: F283180015 X-Rspamd-Server: rspam11 X-HE-Tag: 1725995789-174013 X-HE-Meta: U2FsdGVkX18dFssjn9ajtfvgbLXfFCN2AQF2KKAbN1Zs7AYyq50E+snFSRXbxNFnVuTSOURHFyylcGEWls2Q/1nvbE8ErQmvd5wJrCeuImDTM87musN6alDgabdBipj4xza4HQbmK672/fHW4a4caxI9grMLW5H2R1Xo8ygTlZ1kgr/GU386JGzxsADG908WfAHu+++vtIF3qQaK+BE9hjX98diYjVjHiTeEihOM0+njCVINe5YIZwGNtt5ZMc427LdG6zHrwOipf7aF1ZK0bSJnylMchuc5YE3ZyqSCm1OGjQO7DAztY3jNiPOASYReznKlG36Q4Ct03oG4LYbJLbZqn1fmuRn3DXc0t3NqAK3d6qiD7o//Um8bFaUx/07P1bMBiuLMubQZH7Fyw0g3q1hHVW0MyItAcbuAGGNgGmkrQ/DUPimgcREjsfhx/3a8oeWuu2f7FKmScr1pp4O+IfBArfvbw28ThpvPR6dex5qd0L0H8v3arS0YTjKFC3MicyAHYIpe4ck9zgxrRFw7Y4SuAYcm63EEsSFfv3fS2HgXQzJiyvSgPQbuJGHcXxFGCmDUuYMiDKbI8KFJnFElavzLSEZamFjTUuFmyZ7FYy6rv0+XhOycHXvokCRErGgo+oMsJXJ5pyLlrGZbJLdMrcRTV89S4hUPXuB3TBwxQybt8p5aCw70cYsEpWeBzvvGig+VZMLh8F0Yg0axxUuQN5KUlSX62KHywirMN0hXviq7WC+TuVmOQ0B8cZBV4MybRZAZiwNo9P+Cv0Q6j32riEse01BaibODjvqjbXvuByyDlJO1yqqyJ7HksKjUTshIXbrb8AaN/9pcKor3QK44VgRID6P0tQvH7e+0ExGxcLCshi2QsdQiDTr5lEfQySNFFAtiTIbxeT5L78cD7TT7oBNbxFPg4Z/aGKwfJCixunwsgUNIMBZhVRUa4jMyLzuXQ7ImgMn/gud5KBB8/h6 ZOIu0bEk lEOcS6PgZjONA0W2Ofmz/KQRfaV+SqYjjO6/vsiJ6mlHfblXYx9PclVIyWKszii6AtENrgGL0S+91s1X5UiODKDowiWpvBGsvGtPVmCxptZ1QoxOQhZgH0xpONISzu2vZhpKeT8vztUW27w1w5MKi6191HIi7rmmfKjvWe5vZZNeVX5lJsk9uQ+hAx7Fenh+kkSfGegAdl5v7sHx4C9/4vKUJJ2nJCgp6nz5XYqROb+nLBKxC36Heb08dG3nI2Uk9gtphQzq8lcv9M6t55MUXKJtaIGISjX7oYmPcf2Ec3hXE5Fcszids4Dds+w1KciT8Ix+Mwtooo06a1vk= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: <linux-mm.kvack.org> List-Subscribe: <mailto:majordomo@kvack.org> List-Unsubscribe: <mailto:majordomo@kvack.org> |
Series |
virtio-mem: s390x support
|
expand
|
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 */
Ever since commit 421c175c4d609 ("[S390] Add support for memory hot-add.") we've been using a section size of 256 MiB on s390x 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 s390x, 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. Signed-off-by: David Hildenbrand <david@redhat.com> --- arch/s390/include/asm/sparsemem.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)