public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Youling Tang <youling.tang@linux.dev>
To: Baoquan He <baoquan.he@linux.dev>
Cc: Baoquan He <bhe@redhat.com>,
	Sourabh Jain <sourabhjain@linux.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jonathan Corbet <corbet@lwn.net>, Vivek Goyal <vgoyal@redhat.com>,
	Dave Young <dyoung@redhat.com>,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	linux-doc@vger.kernel.org, Youling Tang <tangyouling@kylinos.cn>
Subject: Re: [PATCH] crash: Support high memory reservation for range syntax
Date: Fri, 17 Apr 2026 17:23:12 +0800	[thread overview]
Message-ID: <a2232eec-34b9-49d0-b671-9a184ef1e4b4@linux.dev> (raw)
In-Reply-To: <ad92ix7d7I8jsykV@MiWiFi-R3L-srv>

On 4/15/26 19:29, Baoquan He wrote:

> On 04/09/26 at 09:55am, Youling Tang wrote:
>> Hi, Baoquan
>>
>> On 4/8/26 21:32, Baoquan He wrote:
>>> On 04/08/26 at 10:01am, Sourabh Jain wrote:
>>>> Hello Youling,
>>>>
>>>> On 04/04/26 13:11, Youling Tang wrote:
>>>>> From: Youling Tang <tangyouling@kylinos.cn>
>>>>>
>>>>> The crashkernel range syntax (range1:size1[,range2:size2,...]) allows
>>>>> automatic size selection based on system RAM, but it always reserves
>>>>> from low memory. When a large crashkernel is selected, this can
>>>>> consume most of the low memory, causing subsequent hardware
>>>>> hotplug or drivers requiring low memory to fail due to allocation
>>>>> failures.
>>>> Support for high crashkernel reservation has been added to
>>>> address the above problem.
>>>>
>>>> However, high crashkernel reservation is not supported with
>>>> range-based crashkernel kernel command-line arguments.
>>>> For example: crashkernel=0M-1G:100M,1G-4G:160M,4G-8G:192M
>>>>
>>>> Many users, including some distributions, use range-based
>>>> crashkernel configuration. So, adding support for high crashkernel
>>>> reservation with range-based configuration would be useful.
>>> Sorry for late response. And I have to say sorry because I have some
>>> negative tendency on this change.
>>>
>>> We use crashkernel=xM|G and crashkernel=range1:size1[,range2:size2,...]
>>> as default setting, so that people only need to set suggested amount
>>> of memory. While crashkernel=,high|low is for advanced user to customize
>>> their crashkernel value. In that case, user knows what's high memory and
>>> low memory, and how much is needed separately to achieve their goal, e.g
>>> saving low memory, taking away more high memory.
>>>
>>> To be honest, above grammers sounds simple, right? I believe both of you
>>> know very well how complicated the current crashkernel code is. I would
>>> suggest not letting them becomre more and more complicated by extending
>>> the grammer further and further. Unless you meet unavoidable issue with
>>> the existing grammer.
>>>
>>> Here comes my question, do you meet unavoidable issue with the existing
>>> grammer when you use crashkernel=range1:size1[,range2:size2,...] and
>>> think it's not satisfactory, and at the same time crashkernel=,high|low
>>> can't meet your demand either?
>> Yes, regular users generally don't know about high memory and low memory,
>> and probably don't know how much crashkernel memory should be reserved
>> either. They mostly just use the default crashkernel parameters configured
>> by the distribution.
>>
>> For advanced users, the current grammar is sufficient, because
>> 'crashkernel=<range1>:<size1>[,<range2>:<size2>,...][@offset],>boundary'
>> can definitely be replaced with 'crashkernel=size,high'.
>>
>> The main purpose of this patch is to provide distributions with a more
>> reasonable default parameter configuration (satisfying most requirements),
>> without having to set different distribution default parameters for
>> different
>> scenarios (physical machines, virtual machines) and different machine
>> models.
> OK, do you have a concrete case? e.g in your distros, what will you set
> with this patchset applied? Let's see if it can cover all cases with one
> simple and satisfying parameter.

For our production deployment across various hardware configurations
(physical servers, VMs with different memory sizes), I'm planning to
use the following crashkernel configuration:
crashkernel=1G-4G:256M,4G-12G:384M,12G-48G:512M,48G-128G:768M,128G-:1024M,>384M

Thanks,
Youling.

  reply	other threads:[~2026-04-17  9:23 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-04  7:41 [PATCH] crash: Support high memory reservation for range syntax Youling Tang
2026-04-08  4:31 ` Sourabh Jain
2026-04-08  7:41   ` Youling Tang
2026-04-08  9:40     ` Sourabh Jain
2026-04-08 13:32   ` Baoquan He
2026-04-09  1:55     ` Youling Tang
2026-04-15 11:29       ` Baoquan He
2026-04-17  9:23         ` Youling Tang [this message]
2026-04-08 11:32 ` Sourabh Jain
2026-04-15  0:28 ` kernel test robot
2026-04-15  1:43 ` kernel test robot
2026-04-15  3:17 ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a2232eec-34b9-49d0-b671-9a184ef1e4b4@linux.dev \
    --to=youling.tang@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=baoquan.he@linux.dev \
    --cc=bhe@redhat.com \
    --cc=corbet@lwn.net \
    --cc=dyoung@redhat.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sourabhjain@linux.ibm.com \
    --cc=tangyouling@kylinos.cn \
    --cc=vgoyal@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox