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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 880C6C4332F for ; Wed, 12 Oct 2022 17:46:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229557AbiJLRqa (ORCPT ); Wed, 12 Oct 2022 13:46:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45848 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229544AbiJLRq2 (ORCPT ); Wed, 12 Oct 2022 13:46:28 -0400 Received: from mail.skyhub.de (mail.skyhub.de [IPv6:2a01:4f8:190:11c2::b:1457]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5F2B4C97F4 for ; Wed, 12 Oct 2022 10:46:27 -0700 (PDT) Received: from zn.tnic (p200300ea9733e705329c23fffea6a903.dip0.t-ipconnect.de [IPv6:2003:ea:9733:e705: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 E58A01EC0230; Wed, 12 Oct 2022 19:46:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1665596782; 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=Meljy89lAYExQlzfDo2HCH7IawAQ8LDvQAy651p5TKE=; b=eZymPjEFV/FwQ8Rxc+xKEUGadAuWqwhaK1hnhI9q3UT0JUCatTADf74Y4LJuMtCmnplwLu WT5stDquCviENtkSPoBEDcHALazjwMlGx+sYEsBNZc2KpzhrIxBA6tBl91O1i1n1GT0EKD 9PU6VGgv4181HTIajDnoQoTkcA1qhXo= Date: Wed, 12 Oct 2022 19:46:18 +0200 From: Borislav Petkov To: Baoquan He Cc: Eric DeVolder , Oscar Salvador , Andrew Morton , david@redhat.com, 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: <20220909210509.6286-1-eric.devolder@oracle.com> <20220909210509.6286-8-eric.devolder@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Oct 08, 2022 at 10:35:14AM +0800, Baoquan He wrote: > Memory hptlug is not limited by a certin or a max number of memory > regions, but limited by how large of the linear mapping range which > physical can be mapped into. Memory hotplug is not limited by some abstract range but by the *actual* possibility of how many DIMM slots on any motherboard can hotplug memory. Certainly not 32K. So you can choose a sane default which covers *all* actual systems out there. > For the Kconfig CRASH_MAX_MEMORY_RANGES Eric added, it's meaningful to > me to set a fixed value which is enough in reality. Yes, exactly. > For extreme testing with special purpose, it could be broken easily, > people need decide by self whether the CONFIG_CRASH_MAX_MEMORY_RANGES > is enlarged or not. I don't want for people to decide on one more thing where they have to go and read a bunch of specs just to know what is a good value. So we should set a sane, *practical* upper limit and simply go with it. Everything else is testing stuff and if you test the kernel, then you can change limits and values and so on as you want to. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette