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 4A1D0ECAAA1 for ; Fri, 28 Oct 2022 10:19:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6EDED6B0072; Fri, 28 Oct 2022 06:19:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 675D86B0073; Fri, 28 Oct 2022 06:19:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 516916B0074; Fri, 28 Oct 2022 06:19:38 -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 3EA056B0072 for ; Fri, 28 Oct 2022 06:19:38 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id D74E41A078F for ; Fri, 28 Oct 2022 10:19:37 +0000 (UTC) X-FDA: 80069961594.01.648DDDF Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by imf30.hostedemail.com (Postfix) with ESMTP id 5227580005 for ; Fri, 28 Oct 2022 10:19:29 +0000 (UTC) Received: from zn.tnic (p200300ea9733e7ce329c23fffea6a903.dip0.t-ipconnect.de [IPv6:2003:ea:9733:e7ce:329c:23ff:fea6:a903]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 369E51EC0523; Fri, 28 Oct 2022 12:19:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1666952361; 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: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=pnKOGkzAqYTHQEPw8aoAjfmGZ1+iB9PnhYVRmuE0Q+s=; b=UNvJ7Vp2kgarN+/wDOtP8BOPFsBNaaHPA1NI5oCgjBJ9RAFITLDoZSaTh1oTF8EC14K3cw rlE1QqX50TPrcfya1eMFzgk9/FDndlTUXLGAot114Ul/iuwJJbMnNePqwCKt9K0d9IJ8ck T93Fq3KVC9ezYRr1EIvrHobwC7hAcnA= Date: Fri, 28 Oct 2022 12:19:16 +0200 From: Borislav Petkov To: Eric DeVolder Cc: Baoquan He , david@redhat.com, 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> <35c98ca6-10f8-b248-78c5-99fce7e66c65@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <35c98ca6-10f8-b248-78c5-99fce7e66c65@oracle.com> Authentication-Results: imf30.hostedemail.com; dkim=temperror ("DNS error when getting key") header.d=alien8.de header.s=dkim header.b=UNvJ7Vp2; spf=temperror (imf30.hostedemail.com: error in processing during lookup of bp@alien8.de: DNS error) smtp.mailfrom=bp@alien8.de; dmarc=temperror reason="query timed out" header.from=alien8.de (policy=temperror) X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 5227580005 X-Stat-Signature: cnq7fzs8jmesugm35ypcmxhcfqrqob9z X-Rspam-User: X-HE-Tag: 1666952369-606582 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 Thu, Oct 27, 2022 at 02:24:11PM -0500, Eric DeVolder wrote: > Be aware, in reality, that if the system was fully populated, it would not > actually consume all 8192 phdrs. Rather /proc/iomem would essentially show a > large contiguous address space which would require just a single phdr. Then that from below: pnum += CONFIG_CRASH_MAX_MEMORY_RANGES; which then would end up allocating 8192 would be a total waste. So why don't you make that number dynamic then? You start with something sensible: total_num_pheaders = num_online_cpus() + "some number of regions" + "some few others" I.e., a number which is a good compromise on the majority of machines. Then, on hotplug events you count how many new regions are coming in and when you reach the total_num_pheaders number, you double it (or some other increase stragegy), reallocate the ELF header buffers etc needed for kdump and you're good. This way, you don't waste memory unnecessarily on the majority of systems and those who need more, get to allocate more. > I'd prefer keeping CRASH_MAX_MEMORY_RANGES as that allow the maximum phdr > number value to be reflective of CPUs and/or memory; not all systems support > both CPU and memory hotplug. For example, I have queued up this change to > reflect this: > > if (IS_ENABLED(CONFIG_HOTPLUG_CPU) || IS_ENABLED(CONFIG_MEMORY_HOTPLUG)) { If you're going to keep CRASH_MAX_MEMORY_RANGES, then you can test only that thing as it expresses the dependency on CONFIG_HOTPLUG_CPU and CONFIG_MEMORY_HOTPLUG already. If you end up making the number dynamic, then you could make that a different Kconfig item which contains all that crash code as most of the people won't need it anyway. Hmm? -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette