From: "H. Peter Anvin" <hpa@zytor.com>
To: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Wen Congyang <wency@cn.fujitsu.com>,
rob@landley.net, tglx@linutronix.de,
Ingo Molnar <mingo@redhat.com>,
x86@kernel.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
bhelgaas@google.com
Subject: Re: [PATCH 1/2 v2] x86: add max_addr boot option
Date: Tue, 12 Jun 2012 20:29:39 -0700 [thread overview]
Message-ID: <4FD80923.1060807@zytor.com> (raw)
In-Reply-To: <4FD7F937.2010101@jp.fujitsu.com>
On 06/12/2012 07:21 PM, Kamezawa Hiroyuki wrote:
>
> But now, we know mem= boot option is buggy....it acts as max_addr=
> option, we have concerns that 'someone may fix mem= option as sane as ia64. because
> it's buggy".
>
> We'd like to fix mem= boot option by ourselves and preserve old behavior
> with max_addr= boot option, which ia64 has.
>
Now I'm *really* confused.
Realistically, there is no point in the old mem= behavior of assuming a
contiguous chunk of memory up to that point; it simply doesn't match how
modern hardware is constructed. Your notion that ia64 is "sane" is
probably more of "outdated" in my opinion.
As such, the current behavior for mem= seems like the right thing and
the change was intentional (not to mention has been in place since
kernel 2.5.65, back in 2003); it also solves your requirements. If you
are concerned about it, it would make more sense to make sure it is
documented as intentional.
In fact, it looks like IA64 introduced a divergence when the max_addr=
patch was introduced in 2004. You're basically proposing the same
divergence for x86 now; talk about having the tail wag the dog.
Sorry. NAK.
-hpa
next prev parent reply other threads:[~2012-06-13 3:30 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-11 8:44 [PATCH 1/2 v2] x86: add max_addr boot option Wen Congyang
2012-06-11 8:46 ` [PATCH 2/2 v2] x86: reimplement mem " Wen Congyang
2012-06-11 17:35 ` [PATCH 1/2 v2] x86: add max_addr " Bjorn Helgaas
2012-06-12 6:29 ` Wen Congyang
2012-06-12 11:30 ` Bjorn Helgaas
2012-06-13 1:55 ` Kamezawa Hiroyuki
2012-06-13 4:59 ` Rob Landley
2012-06-14 2:06 ` Kamezawa Hiroyuki
2012-06-14 20:00 ` Rob Landley
2012-06-11 21:15 ` H. Peter Anvin
2012-06-12 6:26 ` Wen Congyang
2012-06-12 16:10 ` H. Peter Anvin
2012-06-13 2:21 ` Kamezawa Hiroyuki
2012-06-13 3:29 ` H. Peter Anvin [this message]
2012-06-13 5:20 ` Kamezawa Hiroyuki
2012-06-13 5:36 ` Wen Congyang
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=4FD80923.1060807@zytor.com \
--to=hpa@zytor.com \
--cc=bhelgaas@google.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=rob@landley.net \
--cc=tglx@linutronix.de \
--cc=wency@cn.fujitsu.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