Received: by 2002:ac0:b08d:0:0:0:0:0 with SMTP id l13csp4327133imc; Mon, 25 Feb 2019 03:01:29 -0800 (PST) X-Google-Smtp-Source: AHgI3IZqy0aLK5uqcgtZZK4r3Oph9ktxY9smWBJ7hNGVv75ASr+NlQUo1PLYaz7hjRDWWR4WOduI X-Received: by 2002:a62:b801:: with SMTP id p1mr6688246pfe.25.1551092488942; Mon, 25 Feb 2019 03:01:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551092488; cv=none; d=google.com; s=arc-20160816; b=ZO/XAjLML5XGhUed+jweEegL1gN2ujm/3V/aPhLVcRPkkfb4qroyoFiRzEB5hdKo6q fzNaGyB+0LZLhLCkG9alCPhrKZ/1nLs/X1CiisG2Et13pzKbdQSYDE5V+pjwrhtMqHDo tQ9FUHYoV9AV9WNDJlJQqqnDwE0YgNrzMmPN3hzzFV4gDfvGL5QPxZoe+495DGV5cUkn loBtxBJ+UWSf5WME6uPOpTJnkaCbuzQXaG3ROUMyVE3/8SW2Jf5h5lfZ42ZnIv7qtXGR rEeOsSk4o/iXF/hs+5/+3uBoPE+MEgIO8Giwr7ik5OsWDm6UxJjB5DXm3zPCpjeOx6vS jOpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=nuCE6qJALFt2s8pw88tIa2wAT9IDSsgGQP8+Ytx3mds=; b=KjtIZtPREYWq9Jknazd/GY02Drl5ejH+1pHVnYDTchJKBitoj+stuR+lzW+ytqh+t8 2mQPBuUHBpQRXY0mwVwcSVILNb888UUjpDgibQfGS5zw9xkSXodNyVO35CCgXAbB924/ 97yvC5lh/qs1OlgjUFLVzmCEjCugjtfWf28qXT1UDqv/kolmzLigGNZ4zYzOHsgzYPaC xIVzx0QtIStMFJe2Ouzan/HMqThD0S74FL1WTrUHJfKrKWOsjITUKcFVSZ92ojySSnzn A0pobN+aTMAL3JvHoM/UvQVLO4eBy1LNMGYWoJpRh2lt1kbOEwuCixiopr1MK5RgeznX 26Og== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 1si9556805plc.277.2019.02.25.03.01.11; Mon, 25 Feb 2019 03:01:28 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726770AbfBYLAs (ORCPT + 99 others); Mon, 25 Feb 2019 06:00:48 -0500 Received: from mx2.suse.de ([195.135.220.15]:52870 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726648AbfBYLAr (ORCPT ); Mon, 25 Feb 2019 06:00:47 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 81730AD2F; Mon, 25 Feb 2019 11:00:46 +0000 (UTC) Date: Mon, 25 Feb 2019 12:00:43 +0100 From: Joerg Roedel To: Borislav Petkov Cc: Dave Young , bhe@redhat.com, Jerry Hoemann , x86@kernel.org, Randy Dunlap , kexec@lists.infradead.org, linux-kernel@vger.kernel.org, Pingfan Liu , Mike Rapoport , Andrew Morton , yinghai@kernel.org, vgoyal@redhat.com, iommu@lists.linux-foundation.org, konrad.wilk@oracle.com Subject: Re: [PATCHv7] x86/kdump: bugfix, make the behavior of crashkernel=X consistent with kaslr Message-ID: <20190225110043.GA5884@suse.de> References: <20190206120804.GC10062@dhcp-128-65.nay.redhat.com> <20190211204816.GB21473@dhcp-128-65.nay.redhat.com> <20190215102458.GD10433@zn.tnic> <20190218014820.GA10711@dhcp-128-65.nay.redhat.com> <20190220083241.GA3447@zn.tnic> <20190220094146.GA8597@dhcp-128-65.nay.redhat.com> <20190221171321.GD12997@zn.tnic> <20190222021101.GA11654@dhcp-128-65.nay.redhat.com> <20190222084241.GC8380@suse.de> <20190222130026.GA30766@zn.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190222130026.GA30766@zn.tnic> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 22, 2019 at 02:00:26PM +0100, Borislav Petkov wrote: > On Fri, Feb 22, 2019 at 09:42:41AM +0100, Joerg Roedel wrote: > > The current default of 256MB was found by experiments on a bigger > > number of machines, to create a reasonable default that is at least > > likely to be sufficient of an average machine. > > Exactly, and this is what makes sense. > > The code should try the requested reservation and if it fails, it should > try high allocation with default swiotlb size because we need to reserve > *some* range. Right, makes sense. While at it, maybe it is time to move the default allocation policy to 'high' again. The change was reverted six years ago because it broke old kexec tools, but those are probably out-of-service now. I think this change would make the whole crashdump allocation process less fragile. Regards, Joerg