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 1A56CC38A2D for ; Wed, 26 Oct 2022 14:54:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5DE718E0002; Wed, 26 Oct 2022 10:54:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 598298E0001; Wed, 26 Oct 2022 10:54:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 47D0B8E0002; Wed, 26 Oct 2022 10:54:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 36B478E0001 for ; Wed, 26 Oct 2022 10:54:37 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id CFDFD1A108B for ; Wed, 26 Oct 2022 14:54:36 +0000 (UTC) X-FDA: 80063396952.12.AB8BAAE Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf08.hostedemail.com (Postfix) with ESMTP id 4D6FD160015 for ; Wed, 26 Oct 2022 14:54:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1666796075; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8jRuzj8aI2I9CbJusoP/+rcWnTpr8peB8CRFVJrzDj8=; b=e+rJYr5JnsAEdSHO+sqs7TgNNbkpckzOXkM/r3ynanMfLwFysJN/UV2p/y6vn1tB3JeZ87 oizkrh8v4HAXIfWNSDqauc5Dq944YYXmhFQuiO2UWtvwBymRbld9kgR7viuLvQvmMIjWQJ E1DKfGLKs2ubvBmn1xi6Kb0E4J9aZJw= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-251-JdfYWNA1OdSvPb3u62g5TA-1; Wed, 26 Oct 2022 10:54:34 -0400 X-MC-Unique: JdfYWNA1OdSvPb3u62g5TA-1 Received: by mail-wr1-f71.google.com with SMTP id w23-20020adf8bd7000000b002358f733307so6124586wra.17 for ; Wed, 26 Oct 2022 07:54:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:subject:organization:from :references:cc:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8jRuzj8aI2I9CbJusoP/+rcWnTpr8peB8CRFVJrzDj8=; b=mUslcRBjFjU9Yp83YdWfQ3Hwwkg8or0CzGlm+tHDtGmsI71xlkWjBOs1Pd244QahHv 8Hpx1pygpO8yq6slalQ+Zd1tzi1XJrrUG/L3E8lCOTBPfK7hzwFhw7M/HZLb6qiRFWiR 53dKs8Th+778AO7ALvbBgwqPY4kGe5rjx05oRCFwAvVw4mGHfO5dVtLBnET01njB6990 YhEQ20rYhiKIQT7YWUYBzin9eYW6wKVAtFYua8fnIg5PoERVdUlo3iRRp3UrAxnUd7Rp x8j/0mxt3N5EYxD+WoxAQuid44mQ4ZB0A4ir/c4xLW1uAd2HIcdQP/UeGC7Xhrkx2pjc kD6g== X-Gm-Message-State: ACrzQf3Rur1lTudT8dBAcGqLyiQxOXIya+24SLO6HM1KIDu7FCir+njK +IlZ0KfrEHwAS9pW+tM0HSKd3gwNuHEyKqc1BGq0TN0fKmmFyX/UTfoEpn7SKR85yyDiEsoO5Od E8f2iet3sLes= X-Received: by 2002:adf:f6c9:0:b0:236:547f:698a with SMTP id y9-20020adff6c9000000b00236547f698amr18358537wrp.180.1666796073169; Wed, 26 Oct 2022 07:54:33 -0700 (PDT) X-Google-Smtp-Source: AMsMyM58Oi6r6VCYZDISEQe29opH4/96LoWRdQ0kTHG43cIiSkE59tlwcXeKwFPxUQIGviW/ZHEPNw== X-Received: by 2002:adf:f6c9:0:b0:236:547f:698a with SMTP id y9-20020adff6c9000000b00236547f698amr18358523wrp.180.1666796072882; Wed, 26 Oct 2022 07:54:32 -0700 (PDT) Received: from ?IPV6:2003:cb:c706:5b00:c9f4:7535:9360:70d7? (p200300cbc7065b00c9f47535936070d7.dip0.t-ipconnect.de. [2003:cb:c706:5b00:c9f4:7535:9360:70d7]) by smtp.gmail.com with ESMTPSA id j9-20020adfe509000000b0023647841c5bsm5663674wrm.60.2022.10.26.07.54.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 26 Oct 2022 07:54:32 -0700 (PDT) Message-ID: Date: Wed, 26 Oct 2022 16:54:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 To: Baoquan He , Borislav Petkov Cc: Eric DeVolder , 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 References: <53aed03e-2eed-09b1-9532-fe4e497ea47d@oracle.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH v12 7/7] x86/crash: Add x86 crash hotplug support In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=e+rJYr5J; spf=pass (imf08.hostedemail.com: domain of david@redhat.com designates 170.10.129.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=1666796076; a=rsa-sha256; cv=none; b=JAqfeCV8wqaMYJkrHQuEqeA+bpxJO9wD66AU0EtkefFFs2s/qZomtJJaH7lLK+KYrGUKAE Q4xDQLyEi+Ym5ySbnWnko5vXTFo9J2ZkEGslG7XWqqVlWuJ3+atmR9Hguno4sJ7nKPYl1C 2w8VJqEqHlnICmg3wsD8lnG2TQeqnos= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666796076; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=8jRuzj8aI2I9CbJusoP/+rcWnTpr8peB8CRFVJrzDj8=; b=rPkBUDKVPcP+lHI8naPVoQye4pMsupmhCUQF9aBAsnYLZeUyl4CRAoRAknZENoijjkIdhf qGoIJjiD3lFg/fyMx/WhpFTAQ25njmoEagE35HDhjS4N8oYihRwPM9fq8g6oNIAcJ2Ydqv UdA0x/YXDrVy+l8KZa3dpba1B0buVWY= X-Rspamd-Queue-Id: 4D6FD160015 Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=e+rJYr5J; spf=pass (imf08.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Server: rspam02 X-Rspam-User: X-Stat-Signature: pez3cswfweyu87z19h7nd5q9ibairyk3 X-HE-Tag: 1666796076-491074 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 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, David / dhildenb