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=-6.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 5D342C43460 for ; Tue, 11 May 2021 16:31:40 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C82E1613CD for ; Tue, 11 May 2021 16:31:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C82E1613CD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 329796B006E; Tue, 11 May 2021 12:31:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2FFDB6B0070; Tue, 11 May 2021 12:31:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1A2A06B0072; Tue, 11 May 2021 12:31:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0203.hostedemail.com [216.40.44.203]) by kanga.kvack.org (Postfix) with ESMTP id EF8D66B006E for ; Tue, 11 May 2021 12:31:38 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 9FBA3180AAA9F for ; Tue, 11 May 2021 16:31:38 +0000 (UTC) X-FDA: 78129491076.04.8217A07 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf02.hostedemail.com (Postfix) with ESMTP id 4B02440002C0 for ; Tue, 11 May 2021 16:31:04 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 8367D6188B; Tue, 11 May 2021 16:31:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1620750696; bh=uPrfte5KaTPUyCLBFLLIvItx3OL8Fb3NwtKkWVMZC9c=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=E5r4PJfXra6wz1pNqN0eq+N+mzf1jxX1UOkGkhl0pKd6osm/7wcVsGTYSbAGOBPmC vGTthBQV1u8dfWE/Sc+e0wiNsYcF7FEm5e6Ko4uJS+sfFDGVrADbnKHjoa9l5GGBrm DOZ5zBUUST5AjSJtwoYmEoehxPwQff/Sgf+700nHoiJFVuIakInc9UiemolnMclJDq hriT0fbfOEkNypgPB6Aw1gtRAu0F7KS4klr/zyuX7MZrY5gMLNUgEF3IABwDwCVndw t5KQ6pvp6dnFrNCmNeo+LmGU97+Wj/qNTUUb5CK8mQYG3Fjd5AASLY1CY6KYfE96ji qj6CojX0DkM6Q== Date: Tue, 11 May 2021 19:31:23 +0300 From: Mike Rapoport To: Baoquan He Cc: David Hildenbrand , 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 Subject: Re: [patch 48/91] kernel/crash_core: add crashkernel=auto for vmcore creation Message-ID: References: <889c6b90-7335-71ce-c955-3596e6ac7c5a@redhat.com> <20210508085133.GA2946@localhost.localdomain> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210511133641.GE2834@localhost.localdomain> Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=E5r4PJfX; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf02.hostedemail.com: domain of rppt@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=rppt@kernel.org X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 4B02440002C0 X-Stat-Signature: wmzds18ddnbqjc6475yp9dzd7tqitnpb Received-SPF: none (kernel.org>: No applicable sender policy available) receiver=imf02; identity=mailfrom; envelope-from=""; helo=mail.kernel.org; client-ip=198.145.29.99 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1620750664-427556 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: Hi Baoquan, On Tue, May 11, 2021 at 09:36:41PM +0800, Baoquan He wrote: > On 05/10/21 at 01:56pm, David Hildenbrand wrote: > > On 10.05.21 13:44, Dave Young wrote: > > > Hi David, > > > > Hi Dave, > > > > > On 05/10/21 at 01:01pm, David Hildenbrand wrote: > > > [snip] > > > > It also bugged me for quite a bit that we don't have a sane way to achieve > > > > what we're doing here upstream. It somewhat feels like "this doesn't belong > > > > in the kernel and is user policy" but then, the existing kernel support is > > > > suboptimal. > > > > > > > > Maybe reserving some "maybe too big but okayish to boot the system in a sane > > > > environment -- e.g., X% of system RAM and at least Y" size first and > > > > shrinking it later as triggered by user space early (where we do seem to > > > > have a way to pre-calculate things now) might actually be a good direction > > > > to look into. > > > > > > Hmm, that is also an option we considered before. Even for your > > > suggestion we still need a kernel option to set the default ratio/value. > > > and the ratio/value should be another patch which expands crashkernel > > > syntax. > > > > Right. > > > > > > > > Actually the kconfig help text in this patch is indeed misleading, it is > > > not introducing crashkernel=a:b... and no need to explain about the > > > crashkernel syntax, the config option is actually just some interface we > > > can add any valid crashkernel settings to be used by default. So current > > > patch help text describes the default value of crash auto str, instead > > > of describes what crash auto str is. > > > > Right. And I would much rather prefer either > > > > a) handling "auto" completely in the kernel, not just setting some > > questionable default at compile time > > Thanks for the suggestions. > > 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. If we can resize the reservation later during boot this will also address David's concern about the wasted memory. 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? > > b) passing it explicitly in via the cmdline > > > > > > > > And crashkernel=auto makes this more flexibly. We can tune the values > > > easily when upgrading. But if we pass a fixed value in userspace we > > > can not know if the value is set by distribution automatically or by user > > > manually thus we can not blindly update it. > > > > I think there are two different cases: > > > > > > 1. kernel space updates the value later during boot. "crashkernel=auto" > > really does the right thing, meaning > > > > a) allocate something reasonable and safe during early boot > > b) update the allocation during late boot when we know what kind of system > > we're running on > > > > Then, we indeed care about "crashkernel=auto" in the kernel and I think it > > would be a nice thing to have. The only question is on how to make that a > > little configurable, depending on different thingies we might want to run in > > the crashkernel (assuming someone doesn't want kdump). > > > > > > 2. user space updates the value later during boot > > > > IMHO we don't really car who decided on the value as we do the update from > > user space. If an admin messes with crashkernel=, the admin can also mess > > with kdump not doing any overwrites (e.g., make that configurable, or detect > > the overwrite in kdump somehow). > > > > -- > > Thanks, > > > > David / dhildenb > > > > -- Sincerely yours, Mike.