Message-ID: <4FD94738.6030500@jp.fujitsu.com>
Date:	Thu, 14 Jun 2012 11:06:48 +0900
From:	Kamezawa Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To:	Rob Landley <rob@...dley.net>
CC:	Bjorn Helgaas <bhelgaas@...gle.com>,
	Wen Congyang <wency@...fujitsu.com>, tglx@...utronix.de,
	Ingo Molnar <mingo@...hat.com>, x86@...nel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2 v2] x86: add max_addr boot option

(2012/06/13 13:59), Rob Landley wrote:
> On 06/12/2012 08:55 PM, Kamezawa Hiroyuki wrote:
>>>> Currently, I only need to ignore the memory. If we need to ignore a
>>>> node,
>>>> "numa_node=" or similar parameter is a better choice.
>>>
>>> Doesn't the end user have to know the memory map of the system to use
>>> "max_addr="?  How do you know what value to supply?  Do you have to
>>> attempt a boot once to discover the highest address on node 0?  What
>>> if node 0 and node 1 memory are interleaved, so there's some node 1
>>> memory below the highest node 0 address?
>>
>> Current our plan is to avoid asking end-user to fix their boot option by
>> hand even if memory size per node is changed. We'll ship a  hardware, which has
>> _fixed_ physical address range per each node regardless of equipped
>> memory size.
>
> I.E. you'll be configuring this yourself when you ship hardware.
>

yes.

> You're adding an option because you consider it less confusing for your
> end users who are digging into kernel parameters, but you will set this
> new option for your users because they haven't got the information to
> set it themselves?
>

My users don't need to know about hardware settings and the meaning of
kernel params. They'll just do as we ask to do.


>> Problem happens =>  reboot (disable some DIMM) =>  remove memmap= option
>> for avoiding
>> trouble =>  check memory layout again =>fix mem_map= =>  reboot again.
>> This reboot takes much time because the system which have
>> Dynamic-partitioning tends to
>> be big....so, we'd like to have some _relaxed_ way to specify the region
>> of memory.
>>
>> Problem happens =>  reboot (disable some DIMM) =>  no changes required
>> (because we have enough memory hole between Node0 and Node1.)
>
> I'm guessing the above means "or you'll be providing some tool that does
> it when they install/remove memory in the hardware"...
>
>> BTW, how do you think about mem= boot option which works as max_addr=,
>> now ?
>> This caused troubles some times on our support-desk, saying
>> Q. I specified mem=8G boot option but it seems the system has only 7GB....
>> A. it's because of PCI configuration area on 3G-4G address range...
>
> So you're saying there are already two ways to do this, but you want to
> add a third to be less confusing for end users who are modifying the
> linux kernel boot parameters by hand using information only you can
> supply to them?
>
> I'm confused...
>

I'm just saying current mem= implemenation seems buggy because spec. and
impl. doesn't match. So, we're just afraid that someone other than us
will fix it and break our assumption how mem= works. It's dangerous to
build a production on a feature where spec. and impl. doesn't match.
So, we proposed to add max_addr= option for avoiding that situation.

Reading threads, it seems Maintainers says that current 'mem=' have been working
for many years and it's not buggy, it works as expected. It seems no one
will be able to change the implementation. Then, we're okay with using mem=.
We'll just implement mem= option for efi environment. And try to fix the spec.
if possible.

Thanks,
-Kame









--
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