From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 6B4ABC38A02 for ; Sat, 29 Oct 2022 04:27:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 56C3A6B0072; Sat, 29 Oct 2022 00:27:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 51CA86B0073; Sat, 29 Oct 2022 00:27:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3E4456B0074; Sat, 29 Oct 2022 00:27:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 2EDA86B0072 for ; Sat, 29 Oct 2022 00:27:34 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id EE068AB3A9 for ; Sat, 29 Oct 2022 04:27:33 +0000 (UTC) X-FDA: 80072703186.27.E83FF3B Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf25.hostedemail.com (Postfix) with ESMTP id ABD1AA0002 for ; Sat, 29 Oct 2022 04:27:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1667017651; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=cedcTZ1KpEk62+3k25jmR+oGeA+YiQNW5lkM4QZGEoQ=; b=QbXd6iespaORXVBlpFYPP4GJBa4lifBajZ3TMKWaav4+KMWGsw/KYko7OySI0h9pjt4Jwa FdLIAAEsmGAsdOdqR1QZHWufZkFBSOgutK+LLyjjOPasrmM3XHyu4yU5bDV7Y6zKFbEqxU 5GF4z6Ng1bgKoNxtyoF0tYFOxHGUy0k= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-91-xVGiBf9dPrKuARqV1j353A-1; Sat, 29 Oct 2022 00:27:22 -0400 X-MC-Unique: xVGiBf9dPrKuARqV1j353A-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id EC16329AA2F8; Sat, 29 Oct 2022 04:27:21 +0000 (UTC) Received: from localhost (ovpn-12-24.pek2.redhat.com [10.72.12.24]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6FBCA40C6EC3; Sat, 29 Oct 2022 04:27:14 +0000 (UTC) Date: Sat, 29 Oct 2022 12:27:05 +0800 From: Baoquan He To: Eric DeVolder Cc: David Hildenbrand , Borislav Petkov , Oscar Salvador , Andrew Morton , linux-kernel@vger.kernel.org, x86@kernel.org, kexec@lists.infradead.org, ebiederm@xmission.com, dyoung@redhat.com, vgoyal@redhat.com, tglx@linutronix.de, mingo@redhat.com, dave.hansen@linux.intel.com, hpa@zytor.com, nramas@linux.microsoft.com, thomas.lendacky@amd.com, robh@kernel.org, efault@gmx.de, rppt@kernel.org, sourabhjain@linux.ibm.com, linux-mm@kvack.org Subject: Re: [PATCH v12 7/7] x86/crash: Add x86 crash hotplug support Message-ID: References: <53aed03e-2eed-09b1-9532-fe4e497ea47d@oracle.com> <368a61e7-818b-2ee4-8c8b-22218373622d@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <368a61e7-818b-2ee4-8c8b-22218373622d@oracle.com> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667017653; 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-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=cedcTZ1KpEk62+3k25jmR+oGeA+YiQNW5lkM4QZGEoQ=; b=Usk2aiw47UeimCTygu0he+Klbz4rcvIOVB98uibAOn3Yznwvzz29Zo6oeoHFtP4t0wUDuc M19I5hCpFU13sluyzT/0Mji53XikBVkJv7d5Cm84KRW04T19ZOHFNs8+eHyH7+IxtSVV75 KZdDLFKoiBMcNu7aymt+rwbWf+Nd4FQ= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=QbXd6ies; spf=pass (imf25.hostedemail.com: domain of bhe@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=bhe@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667017653; a=rsa-sha256; cv=none; b=yAqskST+oZkBh6RxYoh2I7IG3Z0TxbSK2hSjE0jf4ez2gV6az1wyVGRO7g+DcaOH5p+6KD UP//0nPeucPkDVeN7hNIA241PPjCIojWh+5Wzb1ufKiHgBluw3hArQ/qo0FwsxZkIFubFs VgsLRtKIdKkrRf7eqdE+BAtW9PEospc= X-Stat-Signature: 8ufgocfph4hepupekegbhx16dg9oqti8 X-Rspamd-Queue-Id: ABD1AA0002 Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=QbXd6ies; spf=pass (imf25.hostedemail.com: domain of bhe@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=bhe@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1667017652-959476 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: On 10/27/22 at 02:28pm, Eric DeVolder wrote: > > > On 10/27/22 08:52, Baoquan He wrote: > > On 10/26/22 at 04:54pm, David Hildenbrand wrote: > > > On 26.10.22 16:48, Baoquan He wrote: > > > > On 10/25/22 at 12:31pm, Borislav Petkov wrote: > > > > > On Thu, Oct 13, 2022 at 10:57:28AM +0800, Baoquan He wrote: > > > > > > The concern to range number mainly is on Virt guest systems. > > > > > > > > > > And why would virt emulate 1K hotpluggable DIMM slots and not emulate a > > > > > real machine? > > > > > > IIRC, ACPI only allows for 256 slots. PPC dlpar might provide more. > > > > > > > > > > > Well, currently, mem hotpug is an important feature on virt system to > > > > dynamically increase/shrink memory on the system. If only emulating real > > > > machine, it won't be different than bare metal system. > > > > > > > > IIRC, the ballon driver or virtio-mem feature can add memory board, e.g > > > > 1G, block size is 128M, 8 blocks added. When shrinking this 1G memory > > > > later, it will take best effort way to hot remove memory. Means if any > > > > memory block is occupied, it will be kept there. Finally we could only > > > > remove every second blocks, 4 blocks altogether. Then the left > > > > un-removed blocks will produce 4 separate memory regions. Like this, a > > > > virt guest could have many memory regions in kernel after memory > > > > being added/removed. > > > > > > > > If I am wrong, Please correct me, David. > > > > > > Yes, virtio-mem (but also PPC dlpar) can result in many individual memory > > > blocks with holes in between after hotunplug. Hotplug OTOH, usually tries to > > > "plug" these holes and reduce the total number of memory blocks. It might be > > > rare that our range will be heavily fragmented after unplug, but it's > > > certainly possible. > > > > > > [...] > > > > > > > > > > > Yes, now assume we have a HPE SGI system and it has memory hotplug > > > > capacity. The system itself has already got memory regions more than > > > > 1024. Then when we hot add extra memory board, we want to include the > > > > newly added memory regions into elfcorehdr so that it will be dumped out > > > > in kdump kernel. > > > > > > > > That's why I earlier suggested 2048 for number of memory regions. > > > > > > The more the better, unless "it hurts". Assuming a single memory block is > > > 128 MiB, that would be 256 GiB. > > > > > > Usually, on big systems, the memory block size is 2 GiB. So 4 TiB. > > > > Thanks a lot for these valuable inputs, David. > > > > Hi Boris, Eric > > > > So what's your suggested value for the Kconfig option? > > > > 1) cpu number, 1024? > > 2) memory regions, 2048? > > > > About below draft, any comment? We can decide a value based on our > > knowledge, can adjust later if any real system has more than the number. > > > > +config CRASH_ELF_CORE_PHDRS_NUM > > + depends on CRASH_DUMP && KEXEC_FILE && (HOTPLUG_CPU || MEMORY_HOTPLUG) > > + int > > + default 3072 > > + help > > + For the kexec_file_load path, specify the default number of > > + phdr for the vmcore. E.g the memory regions represented by the > > + 'System RAM' entries in /proc/iomem, the cpu notes of each > > + present cpu stored in /sys/devices/system/cpu/cpuX/crash_notes. > > > > Thanks > > Baoquan > > > > I prefer to keep CRASH_MAX_MEMORY_RANGES, as explained in my response to your message on October 26. > eric Ah, sorry, I mixed it up with NR_CPUS. I went on an office outing yesterday, glad to see you and Boris have made an agreement on the code change and value. Thanks. >