From: Andi Kleen <andi@firstfloor.org>
To: Davidlohr Bueso <davidlohr.bueso@hp.com>
Cc: Andi Kleen <andi@firstfloor.org>,
linux-acpi@vger.kernel.org, zeus@gnu.org,
linux-kernel@vger.kernel.org
Subject: Re: srat: harsh hot-pluggable memory check?
Date: Fri, 11 Jan 2013 21:25:01 +0100 [thread overview]
Message-ID: <20130111202501.GL30577@one.firstfloor.org> (raw)
In-Reply-To: <1357935230.7523.32.camel@buesod1.americas.hpqcorp.net>
On Fri, Jan 11, 2013 at 12:13:50PM -0800, Davidlohr Bueso wrote:
> On Thu, 2013-01-10 at 21:02 +0100, Andi Kleen wrote:
> > > This only mentions that the system supports hot-plugging, and IMHO if the
> > > user decides not to use CONFIG_MEMORY_HOTPLUG, it shouldn't be considered an error.
> > > Therefore would it be ok to drop the check? Or am I missing something?
> >
> > The very strict checks were originally implemented because various early
> > BIOS had largely fictional SRATs, and trusting them blindly caused
> > boot failures or a lot of wasted memory for unnecessary hotplug zones.
> > The wasted memory was mainly a problem with the old memory hotplug
> > implementation that pre-allocated memmaps, that's not a problem anymore.
> > However there may be still some other failure cases.
> >
>
> Would you be willing to take a patch that drops this check then? Or do
> you see any other scenario where it would still be valid?
I don't maintain this code.
Personally I would be vary to any changes in this area, unless you
can very clearly demonstrate that the change cannot break any old
system.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
prev parent reply other threads:[~2013-01-11 20:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-10 19:41 srat: harsh hot-pluggable memory check? Davidlohr Bueso
2013-01-10 20:02 ` Andi Kleen
2013-01-11 20:13 ` Davidlohr Bueso
2013-01-11 20:25 ` Andi Kleen [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=20130111202501.GL30577@one.firstfloor.org \
--to=andi@firstfloor.org \
--cc=davidlohr.bueso@hp.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=zeus@gnu.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