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=-5.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 4655BC433ED for ; Mon, 10 May 2021 11:56:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E4432613C2 for ; Mon, 10 May 2021 11:56:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E4432613C2 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 646366B0070; Mon, 10 May 2021 07:56:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5F6456B0071; Mon, 10 May 2021 07:56:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 497F56B0072; Mon, 10 May 2021 07:56:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0048.hostedemail.com [216.40.44.48]) by kanga.kvack.org (Postfix) with ESMTP id 2E51A6B0070 for ; Mon, 10 May 2021 07:56:46 -0400 (EDT) Received: from smtpin38.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id DB3708249980 for ; Mon, 10 May 2021 11:56:45 +0000 (UTC) X-FDA: 78125169570.38.1FB9DBA Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf06.hostedemail.com (Postfix) with ESMTP id 05217C0007C5 for ; Mon, 10 May 2021 11:56:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1620647804; 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=+TnsE47tQgI8UnY5HPZ8So4cPyew1ZrQDuNwjYAv8VE=; b=OKYgbTSR8BStiVZftKc9U+1UgtoWHoKDU5+/KNa6AgSvayJzBnBLV/aGdH4xtiUf2JQHD2 7xBGkz354Q6nMI5OwMhi8tY+X6B6TY3bGoAQEi96h+QI0zrOZs0dNGOd8Q8X1vla/XDMWc f55MkxUKvJ1KY7lhlN9RXK6i4R/Twfc= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-502-lI239N0OMEqsENvg_vNDYg-1; Mon, 10 May 2021 07:56:43 -0400 X-MC-Unique: lI239N0OMEqsENvg_vNDYg-1 Received: by mail-wr1-f71.google.com with SMTP id d20-20020adfc3d40000b029010e1a640bbfso7406277wrg.21 for ; Mon, 10 May 2021 04:56:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:organization:subject :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=+TnsE47tQgI8UnY5HPZ8So4cPyew1ZrQDuNwjYAv8VE=; b=nV5o/m/yh0DW93PE2E8VnqnYusa85+jOllV/NaiJipyXpcRTA9pjFGgUrWDQS6osVv qqMm9Kn9FKQOkzADUXJRqPQ/7bWAXC+ExdDM47Y0RDAd+B+w/GKaT/snSyy7aeF3OPh0 ikHhCjApF7rkU7EpfcUJcCxgnJO2LVHAaCV6JVU59GirSNugrSEbcl3FqWjjfy9Qdv2S apOy12CV3k3kwZbFKkTSqEjhJwbrG0kZd6/EQTQU/2y07RGw8EqribwRX68Va8cZYJvp BblRhwui+gfIqereqEzxeN2qwlAatNoYexVGExT1UBg6pCTD2J/xNEMzPi6LElpsRis3 YXEg== X-Gm-Message-State: AOAM532ACrdlfAg9AT9ku0RKnsX+4vUytakhPWFOBRyL2B0oCj1HaPuJ vyG+vXhDq6VvoOYNy6pMLCdQBApGZleIUcmPAjque1BJ0b8agwWL+TqK598wV/TBke2wZDtKeXy tOmJsF5fOvWA= X-Received: by 2002:adf:a316:: with SMTP id c22mr29518545wrb.202.1620647801909; Mon, 10 May 2021 04:56:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy+8JpuCb9hMj/upFOdeDKXm66jiAhm2ymsmvNuLP4E4sFgnjgVnI//x4VHlU+WOjAr/jYtAw== X-Received: by 2002:adf:a316:: with SMTP id c22mr29518491wrb.202.1620647801613; Mon, 10 May 2021 04:56:41 -0700 (PDT) Received: from [192.168.3.132] (p5b0c676a.dip0.t-ipconnect.de. [91.12.103.106]) by smtp.gmail.com with ESMTPSA id t7sm22194194wrw.60.2021.05.10.04.56.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 May 2021 04:56:41 -0700 (PDT) To: Dave Young Cc: Baoquan He , Andrew Morton , andreyknvl@google.com, 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, rppt@kernel.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 References: <20210507010432.IN24PudKT%akpm@linux-foundation.org> <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> From: David Hildenbrand Organization: Red Hat Subject: Re: [patch 48/91] kernel/crash_core: add crashkernel=auto for vmcore creation Message-ID: Date: Mon, 10 May 2021 13:56:39 +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: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=OKYgbTSR; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf06.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=david@redhat.com X-Stat-Signature: i8q3dcx74dnkttx8u344b7p1kfhthdo9 X-Rspamd-Queue-Id: 05217C0007C5 X-Rspamd-Server: rspam05 Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf06; 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: 1620647805-460226 Content-Transfer-Encoding: quoted-printable 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 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 ach= ieve >> what we're doing here upstream. It somewhat feels like "this doesn't b= elong >> in the kernel and is user policy" but then, the existing kernel suppor= t 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 direc= tion >> to look into. >=20 > 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. >=20 > Actually the kconfig help text in this patch is indeed misleading, it i= s > not introducing crashkernel=3Da:b... and no need to explain about the > crashkernel syntax, the config option is actually just some interface w= e > can add any valid crashkernel settings to be used by default. So curren= t > 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=20 questionable default at compile time b) passing it explicitly in via the cmdline >=20 > And crashkernel=3Dauto 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 us= er > 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=3Dauto"= =20 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=20 system we're running on Then, we indeed care about "crashkernel=3Dauto" in the kernel and I think= =20 it would be a nice thing to have. The only question is on how to make=20 that a little configurable, depending on different thingies we might=20 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=20 from user space. If an admin messes with crashkernel=3D, the admin can=20 also mess with kdump not doing any overwrites (e.g., make that=20 configurable, or detect the overwrite in kdump somehow). --=20 Thanks, David / dhildenb