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 X-Spam-Level: X-Spam-Status: No, score=-8.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 67C83C433ED for ; Wed, 12 May 2021 15:07:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DBB9661434 for ; Wed, 12 May 2021 15:07:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DBB9661434 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2D9D66B0071; Wed, 12 May 2021 11:07:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2232D6B0073; Wed, 12 May 2021 11:07:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0194D6B0072; Wed, 12 May 2021 11:07:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0148.hostedemail.com [216.40.44.148]) by kanga.kvack.org (Postfix) with ESMTP id C12626B006C for ; Wed, 12 May 2021 11:07:30 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 65FDBA2AC for ; Wed, 12 May 2021 15:07:30 +0000 (UTC) X-FDA: 78132907860.23.D063DD6 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf12.hostedemail.com (Postfix) with ESMTP id 87AA2F3 for ; Wed, 12 May 2021 15:07:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1620832049; 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=n82irjIhe0eF7j91gjE3MGjiXR1yJN3bFoEkSd04KR4=; b=fRQ3CuMqYAm3kAnCxUSf/dUfFE7VLQ3YKRWQlk/9xoAZDV2OHejhHQWsJgzxMF8YfjzyYF JHkFZ2lEyYIDyOEXbvBpcIax9gWUYxQwlBXrD084rTNjGLV7BCHePchVZhFwMiB+QpKsHB xX8LhvDfP3E6mJcUGa82c/yTxJuiEuk= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-290-y44HOXNJPo6mOhD2zh9ySQ-1; Wed, 12 May 2021 11:07:26 -0400 X-MC-Unique: y44HOXNJPo6mOhD2zh9ySQ-1 Received: by mail-wm1-f72.google.com with SMTP id l185-20020a1c25c20000b029014b0624775eso680251wml.6 for ; Wed, 12 May 2021 08:07:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=n82irjIhe0eF7j91gjE3MGjiXR1yJN3bFoEkSd04KR4=; b=niJIIdCuCZyX0BBrEmv0b3tDeXVpKrIwG74EgtqTTgQe+crRejGuLKMcbDjOnxeVlY wMI6m3cZm6+4aXjZs4Bh+4mprPldyAS8C43uYw+1kkO7IBElQVeOUDCBVOPkdO+iDo1H 91+yxPCzbhZVwYBsTI3GhxMe8vhpyvORDoIS8Ymr1N3GNZttnu2KqtIRhgZq6lVoy2ig q6sOYcREe2R5nFdJlibvhYw9BwlxBEUQ1OmNY50IiLgmNe7h9XplfTP5gr73uC9v9iJv 3Wu+dHz2+HQyGnGlB12LuFWgIcvFA9SXKAz7qr6+zKcoLMY+GbZlT1+H5ir49ch7fWZh J48g== X-Gm-Message-State: AOAM533Isa03DWxWl5IUN70LA3TgBGR3co/Laels+x7ym7XLTRYn9ADm y2ol6Rzvyh8usqH/c029AoDHmWwVD5e2UHWwRBi+PDUD1KNNa1R8iBLynMn/+mVP9T3/leeVKgo KNzMVa8N8cWQ= X-Received: by 2002:a5d:5109:: with SMTP id s9mr9698184wrt.231.1620832044257; Wed, 12 May 2021 08:07:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw2PLH0xzVUydBEr2/P4vHtfcE2tTQpXMKD1PLnuaHaRml6a+zgDXSWu17dUqyh+Wp8oiNE3Q== X-Received: by 2002:a5d:5109:: with SMTP id s9mr9698110wrt.231.1620832043796; Wed, 12 May 2021 08:07:23 -0700 (PDT) Received: from [192.168.3.132] (p5b0c65ab.dip0.t-ipconnect.de. [91.12.101.171]) by smtp.gmail.com with ESMTPSA id x10sm3864681wro.66.2021.05.12.08.07.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 12 May 2021 08:07:23 -0700 (PDT) Subject: Re: [patch 48/91] kernel/crash_core: add crashkernel=auto for vmcore creation To: Baoquan He Cc: Mike Rapoport , Dave Young , Andrew Morton , christian.brauner@ubuntu.com, colin.king@canonical.com, corbet@lwn.net, frederic@kernel.org, gpiccoli@canonical.com, john.p.donnelly@oracle.com, jpoimboe@redhat.com, keescook@chromium.org, linux-mm@kvack.org, masahiroy@kernel.org, mchehab+huawei@kernel.org, mike.kravetz@oracle.com, mingo@kernel.org, mm-commits@vger.kernel.org, paulmck@kernel.org, peterz@infradead.org, rdunlap@infradead.org, rostedt@goodmis.org, saeed.mirzamohammadi@oracle.com, samitolvanen@google.com, sboyd@kernel.org, tglx@linutronix.de, torvalds@linux-foundation.org, vgoyal@redhat.com, yifeifz2@illinois.edu, Michal Hocko , kasong@redhat.com References: <2d0f53d9-51ca-da57-95a3-583dc81f35ef@redhat.com> <20210510045338.GB2946@localhost.localdomain> <4a544493-0622-ac6d-f14b-fb338e33b25e@redhat.com> <20210510104359.GC2946@localhost.localdomain> <20210511133641.GE2834@localhost.localdomain> <20210512145150.GG2834@localhost.localdomain> From: David Hildenbrand Organization: Red Hat Message-ID: <3897d7a7-1120-4445-c297-e1cb7ac99f43@redhat.com> Date: Wed, 12 May 2021 17:07:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <20210512145150.GG2834@localhost.localdomain> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 87AA2F3 Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=fRQ3CuMq; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf12.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=david@redhat.com X-Rspamd-Server: rspam03 X-Stat-Signature: ppokrtabt1ssenof4mj7g3sj7wnpyh8w Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf12; identity=mailfrom; envelope-from=""; helo=us-smtp-delivery-124.mimecast.com; client-ip=170.10.133.124 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1620832033-214982 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 12.05.21 16:51, Baoquan He wrote: > On 05/11/21 at 07:07pm, David Hildenbrand wrote: >>>> If the way adding default value into kernel config is disliked, >>>> this a) option looks good. We can get value with x% of system RAM, but >>>> clamp it with CRASH_KERNEL_MIN/MAX. The CRASH_KERNEL_MIN/MAX may need be >>>> defined with a default value for different ARCHes. It's very close to >>>> our current implementation, and handling 'auto' in kernel. >>>> >>>> And kernel config provided so that people can tune the MIN/MAX value, >>>> but no need to post patch to do the tuning each time if have to? >>> Maybe I'm missing something, but the whole point is to avoid kernel >>> configuration option at all. If the crashkernel=auto works good for 99% of >>> the cases, there is no need to provide build time configuration along with >>> it. There are plenty of ways users can control crashkernel reservations >>> with the existing 2-4 (depending on architecture) command line options. >>> >>> Simply hard coding a reasonable defaults (e.g. >>> "1G-64G:128M,64G-1T:256M,1T-:512M"), and using these defaults when >>> crashkernel=auto is set would cover the same 99% of users you referred to. >> >> Right, and we can easily allocate a bit more as a safety net temporarily >> when we can actually shrink the area later. >> >>> >>> If we can resize the reservation later during boot this will also address >>> David's concern about the wasted memory. >>> >> >> Yes. >> >>> You mentioned that amount of memory that is required for crash kernel >>> reservation depends on the devices present on the system. Is is possible to >>> detect how much memory is required at late stages of boot? >> >> Here is my thinking: >> >> There seems to be some kind of formula we can roughly use to come up with >> the final crashkernel size. Baoquan for sure knows all the dirty details, I >> assume it's roughly "core kernel + drivers + user space". >> >> In the kernel, we can only come up with "core kernel + drivers" expecting >> that we will run >> >> a) roughly the same kernel >> b) with roughly the same drivers > > As replied to Mike, kernel size is undecided for different kernel with > different configs. We can define a default minimal size to cover kernel > and driver on systems with not many devices, but hardcoding the size I never talked about hardcoding, did I? > into upstream is not helpful. If the size is big, users will be asked to > check and shrink always. If the size is too small, a new value need be > got and added to cmdline and reboot. -- Thanks, David / dhildenb