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 8DC70C433B4 for ; Tue, 11 May 2021 17:07:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0DB8461352 for ; Tue, 11 May 2021 17:07:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0DB8461352 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 4FD376B006E; Tue, 11 May 2021 13:07:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4863D6B0070; Tue, 11 May 2021 13:07:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2B1B36B0072; Tue, 11 May 2021 13:07:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0106.hostedemail.com [216.40.44.106]) by kanga.kvack.org (Postfix) with ESMTP id 0A9046B006E for ; Tue, 11 May 2021 13:07:27 -0400 (EDT) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id AC4624DB8 for ; Tue, 11 May 2021 17:07:26 +0000 (UTC) X-FDA: 78129581292.02.487FD38 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf03.hostedemail.com (Postfix) with ESMTP id F41E6C0007C8 for ; Tue, 11 May 2021 17:07:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1620752845; 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=9EbRT7m80ia45DWilFnPXJ2jbo6G+WKu1DAYy3qgx7c=; b=FzyFCN4uA2L9yATTx38Hoz7b+qOtPJaJlCgxeGz5EOdNysrMSojYFZiRZeBm8Q9f1MMimk KiKYdLkqOZghNnZ/oy5gRUhKM2k/LaTJO4/5nT59Bi95AmHCc2i2gwR7D+05u668HuxvRh sS2dTPSwmZUxlF9DDmM0B2a/5H9V0po= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-241-BppkcXo0Owu6QwkMeLBlWw-1; Tue, 11 May 2021 13:07:24 -0400 X-MC-Unique: BppkcXo0Owu6QwkMeLBlWw-1 Received: by mail-wm1-f70.google.com with SMTP id j136-20020a1c238e0000b029014675462236so2532308wmj.7 for ; Tue, 11 May 2021 10:07:23 -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=9EbRT7m80ia45DWilFnPXJ2jbo6G+WKu1DAYy3qgx7c=; b=ZzJW7dWW5fwWaQ5dNIzPKR8sixW6A9EkBBbZ1der8VFAciDZPnmtDbyv0NkzU8eEwU LypMSWffMmCNUaYp4nXXgoRNaxQ1sgFVzR2PVWS/41cm3hruanW1In/7lrYMYGYoFJAA vVr8EAvedZSkmwI+Y9LOo47PyjVDyNIvsrSkbjBlRGcNECTmcPKfm2QJcg3o48m2aGLN bPXgGGSGChYk2/m4WkXWWse4V0zdw4TLJ5Y2O8KURh17TuwwrQHHZSfDpuxSjVKjxNvF rpDMHQsla3gV5+U8/oz5K/ji33zBk6qPnivfHSG65ijIcK6cyefn+9mxAfmi/EmFqjzd euoQ== X-Gm-Message-State: AOAM531DG3iJGudG6S72nZQwb8cKoLPviCYK73VEWD51E/qlTC1ReRlq anlV3SeNppmgZMZoUWgbdqePIDAL5hruOGbiQzm5mY/U0sKrnJ5sspbBDQg0umpE1/i+1h5sT/z lPuW/MTs8wfg= X-Received: by 2002:a5d:64eb:: with SMTP id g11mr40054332wri.260.1620752842124; Tue, 11 May 2021 10:07:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzvLJLtAPwugWbhm7GJO/QnAAcrCFtXbccBplHV6OpS/TrRD7fjbJjpSzy2gRAvKbm9mKAFqg== X-Received: by 2002:a5d:64eb:: with SMTP id g11mr40054275wri.260.1620752841830; Tue, 11 May 2021 10:07:21 -0700 (PDT) Received: from [192.168.3.132] (p5b0c6329.dip0.t-ipconnect.de. [91.12.99.41]) by smtp.gmail.com with ESMTPSA id d15sm27843323wrw.71.2021.05.11.10.07.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 11 May 2021 10:07:21 -0700 (PDT) To: Mike Rapoport , Baoquan He Cc: 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: <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> From: David Hildenbrand Organization: Red Hat Subject: Re: [patch 48/91] kernel/crash_core: add crashkernel=auto for vmcore creation Message-ID: Date: Tue, 11 May 2021 19:07:19 +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: imf03.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=FzyFCN4u; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf03.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 216.205.24.124) smtp.mailfrom=david@redhat.com X-Stat-Signature: yyjxzzhbjss1s1jtebjq15fmkcxdghk9 X-Rspamd-Queue-Id: F41E6C0007C8 X-Rspamd-Server: rspam02 Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf03; identity=mailfrom; envelope-from=""; helo=us-smtp-delivery-124.mimecast.com; client-ip=216.205.24.124 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1620752837-696621 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: >> 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? > =20 > Maybe I'm missing something, but the whole point is to avoid kernel > configuration option at all. If the crashkernel=3Dauto works good for 9= 9% of > the cases, there is no need to provide build time configuration along w= ith > it. There are plenty of ways users can control crashkernel reservations > with the existing 2-4 (depending on architecture) command line options. >=20 > Simply hard coding a reasonable defaults (e.g. > "1G-64G:128M,64G-1T:256M,1T-:512M"), and using these defaults when > crashkernel=3Dauto is set would cover the same 99% of users you referre= d to. Right, and we can easily allocate a bit more as a safety net temporarily=20 when we can actually shrink the area later. >=20 > If we can resize the reservation later during boot this will also addre= ss > David's concern about the wasted memory. >=20 Yes. > You mentioned that amount of memory that is required for crash kernel > reservation depends on the devices present on the system. Is is possibl= e 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=20 with the final crashkernel size. Baoquan for sure knows all the dirty=20 details, I assume it's roughly "core kernel + drivers + user space". In the kernel, we can only come up with "core kernel + drivers"=20 expecting that we will run a) roughly the same kernel b) with roughly the same drivers The "user space" part is completely under user space control, depending=20 on what application will be run after kexec. So I wonder if something like crashkernel=3Dauto,100M whereby "100M" corresponds to user space demands in addition to the=20 variable part depend on the current kernel + drivers. would already be somewhat sufficient for main use cases I guess. Of course, that approach will get more complicated if the user space=20 portion heavily depends on the drivers etc. Then we need more tunables. --=20 Thanks, David / dhildenb