[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141202145602.GK3156@suse.de>
Date: Tue, 2 Dec 2014 15:56:02 +0100
From: Joerg Roedel <jroedel@...e.de>
To: Baoquan He <baoquan.he@...il.com>
Cc: Joerg Roedel <joro@...tes.org>, Ingo Molnar <mingo@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
x86@...nel.org, linux-kernel@...r.kernel.org,
Vivek Goyal <vgoyal@...hat.com>, Dave Young <dyoung@...hat.com>
Subject: Re: [PATCH 0/3] Fix kdump failures with crashkernel=high
On Tue, Dec 02, 2014 at 07:30:09PM +0800, Baoquan He wrote:
> 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.
In the first kernel the defaults work fine because it has plenty of
low-memory (below 4GB) to allocate from. But in the kdump kernel there
are only 72MB by default, which showed to not be enough to reliably boot
with certain hardware in the machine.
> 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.
I think the kernel should set sane defaults if possible. But to not
increase memory usage for kdump too much, how about subtracting the
amount of low-memory allocated for kdump from the high-mem amount? This
would not increase the overall memory usage.
Joerg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists