From: Joerg Roedel <joro@8bytes.org>
To: Yinghai Lu <yinghai@kernel.org>
Cc: Baoquan He <bhe@redhat.com>, Borislav Petkov <bp@alien8.de>,
Ingo Molnar <mingo@kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/3] x86/crash: Allocate enough low memory when crashkernel=high
Date: Thu, 11 Jun 2015 08:44:10 +0200 [thread overview]
Message-ID: <20150611064410.GF20384@8bytes.org> (raw)
In-Reply-To: <CAE9FiQWY-7fJ1AoAsD1b6O6ExgKriSC+DaeTO8NUuKZ_Jhre8w@mail.gmail.com>
On Wed, Jun 10, 2015 at 10:48:14AM -0700, Yinghai Lu wrote:
> So under 4G low ram is tight, with changing default to 256M is just lazy
> and punishing the other system that does not need that.
> those systems do not need to have "crashkernel=xx,low" before.
The definition of 'default' is that it should be a good value to work
(ideally) everywhere. The previous value did not fulfill this
definition, as on systems without (an enabled) hardware IOMMU and some
32bit-DMA-only devices the crashkernel quickly ran out of low-mem with
it.
And the new default value is not just one that we guessed as being a
better one. Both Baoquan and me did testing on affected systems and
after a discussion we agreed on it.
> should have other smart way to detect and update the default value.
> even dmi blacklist way is better than just changing default value.
DMI information is not enough, it is about the availability of a
hardware IOMMU and the amount and kind of devices needing low-mem for
DMA. This means introducing heuristics, which is often the worst
solution, because heuristics are complex and if we fix it for one
machine we might break many others. So changing the default to a more
workable value is the best solution imho.
But if you have a better idea I am happy to review your patches.
Joerg
prev parent reply other threads:[~2015-06-11 6:44 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-08 7:49 [PATCH 0/3] tip queue 2015-06-08 Borislav Petkov
2015-06-08 7:49 ` [PATCH 1/3] swiotlb: Warn on allocation failure in swiotlb_alloc_coherent() Borislav Petkov
2015-06-08 7:49 ` [PATCH 2/3] x86/swiotlb: Try coherent allocations with __GFP_NOWARN Borislav Petkov
2015-06-08 7:49 ` [PATCH 3/3] x86/crash: Allocate enough low memory when crashkernel=high Borislav Petkov
2015-06-09 0:20 ` Yinghai Lu
2015-06-10 7:04 ` Baoquan He
2015-06-10 17:48 ` Yinghai Lu
2015-06-11 0:36 ` Baoquan He
2015-06-11 6:44 ` Joerg Roedel [this message]
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=20150611064410.GF20384@8bytes.org \
--to=joro@8bytes.org \
--cc=bhe@redhat.com \
--cc=bp@alien8.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@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