linux-kernel - Re: [PATCH 1/2 v2] x86: add max

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4FD81E27.4000006@landley.net>
Date:	Tue, 12 Jun 2012 23:59:19 -0500
From:	Rob Landley <rob@...dley.net>
To:	Kamezawa Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
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

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.

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?

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

> Even if our requirement can be covered current mem= option, I'd like to
> have max_addr= option and make mem= option to be sane as ia64.

"sane as ia64".

Ok, I've read that phrase five times and the words still don't fit together.

I'm going to admit defeat on my attempt to understand this thread, and
move on...

Rob
-- 
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation.  Pick one.
--
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/