From: Baoquan He <baoquan.he@gmail.com>
To: Joerg Roedel <joro@8bytes.org>, Ingo Molnar <mingo@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
Joerg Roedel <jroedel@suse.de>, Vivek Goyal <vgoyal@redhat.com>,
Dave Young <dyoung@redhat.com>
Subject: Re: [PATCH 0/3] Fix kdump failures with crashkernel=high
Date: Tue, 02 Dec 2014 19:30:09 +0800 [thread overview]
Message-ID: <547DA2C1.30902@gmail.com> (raw)
In-Reply-To: <1417174149-31210-1-git-send-email-joro@8bytes.org>
On 11/28/2014 07:29 PM, Joerg Roedel wrote:
> Hi,
>
> here is a patch-set to fix failed kdump kernel boots when
> the systems was booted with crashkernel=X,high. On those
> systems the kernel allocates only 72MiB of low-memory for
> DMA buffers, which showed to be too low on some systems.
>
> The problem is that 64MiB of the low-memory is allocated by
> swiotlb, leaving 8MB for the page-allocator. But swiotlb
> tries to allocate DMA memory from the page-allocator first,
> which fails pretty fast in the boot sequence, causing
> warnings. This patch-set removes these warnings.
>
> But even the 64MiB for swiotlb are eaten up on some systems,
> so that the default of low-memory allocated for the
> crash-kernel is increase from 72MB to 256MB (only changing
> the defaults, can still be overwritten by crashkernel=X,low).
Hi Joerg,
The default low memory is calculated in swiotlb_size_or_default(), and
this relies on IO_TLB_DEFAULT_SIZE which is default value for swiotlb.
If this doesn't work for your case in kdump kernel, does the default
value IO_TLB_DEFAULT_SIZE work for swiotlb in 1st kenrel? If not, user
knows it and should know it will fail for kdump kernel either with
default vaule, user can specify that by crashkernel=x,low which is why
it's introduced.
It may not be a good idea to increase the default low value from 72M to
256M. After all the case you are encountering is a special case, special
case need be treated specially, namely specify it in crashkernel=x,low
clearly.
Thanks
Baoquan
>
> This number comes from experiments on the affected systems,
> 128MiB low-memory was still not enough there, thus I set the
> value to 256MiB to fix the issues.
>
> Any feedback appreciated.
>
> Thanks,
>
> Joerg
>
> Joerg Roedel (3):
> swiotlb: Warn on allocation failure in swiotlb_alloc_coherent
> x86, swiotlb: Try coherent allocations with __GFP_NOWARN
> x86, crash: Allocate enough low-mem when crashkernel=high
>
> arch/x86/kernel/pci-swiotlb.c | 8 ++++++++
> arch/x86/kernel/setup.c | 5 ++++-
> lib/swiotlb.c | 11 +++++++++--
> 3 files changed, 21 insertions(+), 3 deletions(-)
>
next prev parent reply other threads:[~2014-12-02 11:32 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-28 11:29 [PATCH 0/3] Fix kdump failures with crashkernel=high Joerg Roedel
2014-11-28 11:29 ` [PATCH 1/3] swiotlb: Warn on allocation failure in swiotlb_alloc_coherent Joerg Roedel
2014-12-01 20:28 ` Konrad Rzeszutek Wilk
2014-12-02 14:41 ` Joerg Roedel
2014-12-02 18:46 ` Konrad Rzeszutek Wilk
2014-12-03 10:26 ` Joerg Roedel
2014-12-11 19:08 ` Konrad Rzeszutek Wilk
2014-11-28 11:29 ` [PATCH 2/3] x86, swiotlb: Try coherent allocations with __GFP_NOWARN Joerg Roedel
2014-12-01 20:28 ` Konrad Rzeszutek Wilk
2014-12-02 14:45 ` Joerg Roedel
2014-12-02 18:46 ` Konrad Rzeszutek Wilk
2014-12-03 10:27 ` Joerg Roedel
2014-11-28 11:29 ` [PATCH 3/3] x86, crash: Allocate enough low-mem when crashkernel=high Joerg Roedel
2014-12-02 11:30 ` Baoquan He [this message]
2014-12-02 14:56 ` [PATCH 0/3] Fix kdump failures with crashkernel=high Joerg Roedel
2014-12-03 4:01 ` WANG Chao
2014-12-03 10:35 ` Joerg Roedel
2014-12-03 15:19 ` WANG Chao
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=547DA2C1.30902@gmail.com \
--to=baoquan.he@gmail.com \
--cc=dyoung@redhat.com \
--cc=hpa@zytor.com \
--cc=joro@8bytes.org \
--cc=jroedel@suse.de \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=vgoyal@redhat.com \
--cc=x86@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;
as well as URLs for NNTP newsgroup(s).