From: Joerg Roedel <jroedel@suse.de>
To: Dave Young <dyoung@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>,
bhe@redhat.com, Jerry Hoemann <jerry.hoemann@hpe.com>,
x86@kernel.org, Randy Dunlap <rdunlap@infradead.org>,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
Pingfan Liu <kernelfans@gmail.com>,
Mike Rapoport <rppt@linux.vnet.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
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
Date: Fri, 22 Feb 2019 09:42:41 +0100 [thread overview]
Message-ID: <20190222084241.GC8380@suse.de> (raw)
In-Reply-To: <20190222021101.GA11654@dhcp-128-65.nay.redhat.com>
On Fri, Feb 22, 2019 at 10:11:01AM +0800, Dave Young wrote:
> In case people have a lot of devices need more swiotlb, then he manually
> set the ,high with ,low together.
The option to specify the high and low values for the crashkernel are
important for certain machines. The point is that swiotlb already
allocates 64MB of low memory by default. But that memory is only used
for 32bit DMA-mask devices that want to DMA into high memory. There are
drivers just allocating GFP_DMA32 memory, which also ends up in the low
region (but not swiotlb), that is why the previous default of 72MB low
memory was not enough, it only left 8MB of GFP_DMA32 memory. 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.
There is no way today for the kernel to find an optimum value for the
amount of low memory required to successfully create a crash dump. It
depends on the amount of devices in the system and how the drivers
for them are written. The drivers have no way to report back their
requirements, and even if they had, at the time the allocation happens
no driver is loaded yet.
So it is up to the system administrator to find workable values for the
high and low memory requirements, even using experiments as a last
resort.
Regards,
Joerg
next prev parent reply other threads:[~2019-02-22 8:42 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-21 5:16 [PATCHv7] x86/kdump: bugfix, make the behavior of crashkernel=X consistent with kaslr Pingfan Liu
2019-01-21 6:24 ` Baoquan He
2019-01-25 10:39 ` Borislav Petkov
2019-01-25 13:45 ` Dave Young
2019-01-25 14:08 ` Borislav Petkov
2019-01-28 9:58 ` Dave Young
2019-01-28 10:18 ` Borislav Petkov
2019-06-07 17:30 ` Borislav Petkov
2019-06-10 6:51 ` Dave Young
2019-01-29 5:25 ` Pingfan Liu
2019-01-31 7:42 ` Dave Young
2019-01-31 7:59 ` Dave Young
2019-01-31 10:57 ` Borislav Petkov
2019-01-31 22:27 ` Jerry Hoemann
2019-01-31 23:47 ` Borislav Petkov
2019-02-04 22:30 ` Jerry Hoemann
2019-02-05 8:15 ` Borislav Petkov
2019-02-06 12:08 ` Dave Young
2019-02-11 20:48 ` Dave Young
2019-02-12 5:35 ` Pingfan Liu
2019-02-15 10:24 ` Borislav Petkov
2019-02-18 1:48 ` Dave Young
2019-02-20 7:38 ` Pingfan Liu
2019-02-20 8:32 ` Borislav Petkov
2019-02-20 9:41 ` Dave Young
2019-02-20 12:51 ` Pingfan Liu
2019-02-21 17:13 ` Borislav Petkov
2019-02-22 2:11 ` Dave Young
2019-02-22 8:42 ` Joerg Roedel [this message]
2019-02-22 13:00 ` Borislav Petkov
2019-02-24 13:25 ` Pingfan Liu
2019-02-25 1:53 ` Dave Young
2019-02-25 9:39 ` Borislav Petkov
2019-02-25 11:00 ` Joerg Roedel
2019-02-25 11:12 ` Dave Young
2019-02-25 11:30 ` Borislav Petkov
2019-03-01 3:04 ` Pingfan Liu
2019-03-01 3:19 ` Pingfan Liu
2019-03-22 8:22 ` Dave Young
2019-01-29 5:51 ` Pingfan Liu
2019-01-31 10:50 ` Borislav Petkov
-- strict thread matches above, loose matches on Subject: below --
2019-01-15 8:07 Pingfan Liu
2019-01-18 3:43 ` Dave Young
2019-01-19 1:25 ` Jerry Hoemann
2019-01-21 5:11 ` Pingfan Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190222084241.GC8380@suse.de \
--to=jroedel@suse.de \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=bp@alien8.de \
--cc=dyoung@redhat.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jerry.hoemann@hpe.com \
--cc=kernelfans@gmail.com \
--cc=kexec@lists.infradead.org \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rdunlap@infradead.org \
--cc=rppt@linux.vnet.ibm.com \
--cc=vgoyal@redhat.com \
--cc=x86@kernel.org \
--cc=yinghai@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox