[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190222021101.GA11654@dhcp-128-65.nay.redhat.com>
Date: Fri, 22 Feb 2019 10:11:01 +0800
From: Dave Young <dyoung@...hat.com>
To: Borislav Petkov <bp@...en8.de>
Cc: bhe@...hat.com, Jerry Hoemann <jerry.hoemann@....com>,
x86@...nel.org, Randy Dunlap <rdunlap@...radead.org>,
kexec@...ts.infradead.org, linux-kernel@...r.kernel.org,
Pingfan Liu <kernelfans@...il.com>,
Mike Rapoport <rppt@...ux.vnet.ibm.com>,
Andrew Morton <akpm@...ux-foundation.org>, yinghai@...nel.org,
vgoyal@...hat.com, iommu@...ts.linux-foundation.org,
konrad.wilk@...cle.com, Joerg Roedel <jroedel@...e.de>
Subject: Re: [PATCHv7] x86/kdump: bugfix, make the behavior of crashkernel=X
consistent with kaslr
On 02/21/19 at 06:13pm, Borislav Petkov wrote:
> On Wed, Feb 20, 2019 at 05:41:46PM +0800, Dave Young wrote:
> > Previously Joerg posted below patch, maybe he has some idea. Joerg?
>
> Isn't it clear from the commit message?
Then, does it answered your question?
256M is set as a default value in the patch, but it is not a predict to
satisfy all use cases, from the description it is also possible that some
people run out of the 256M and the ,low and ,high format is still
necessary to exist even if we make crashkernel=X do the allocation
automatically in high in case failed in low area.
crashkernel=X: allocate in low first, if not possible, then allocate in
high
In case people have a lot of devices need more swiotlb, then he manually
set the ,high with ,low together.
What's your suggestion then? remove ,low and ,high and increase default
256M in case we get failure bug report?
Powered by blists - more mailing lists