linux-kernel - Re: [PATCH] - Increase max physical memory size of x86

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]

Date:	Thu, 27 Mar 2008 18:30:27 +0100
From:	Andreas Herrmann <andreas.herrmann3@....com>
To:	Chris Snook <csnook@...hat.com>
Cc:	Jack Steiner <steiner@....com>, mingo@...e.hu, ak@...e.de,
	tglx@...utronix.de, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] - Increase max physical memory size of x86_64

On Tue, Mar 25, 2008 at 05:02:46PM -0400, Chris Snook wrote:
> Jack Steiner wrote:
>> On Tue, Mar 25, 2008 at 05:41:54PM +0100, Andreas Herrmann wrote:
>>> On Fri, Mar 21, 2008 at 08:31:57AM -0500, Jack Steiner wrote:
>>>> Increase the maximum physical address size of x86_64 system
>>>> to 44-bits. This is in preparation for future chips that
>>>> support larger physical memory sizes.
>>> Shouldn't this be increased to 48?
>>> AMD family 10h CPUs actually support 48 bits for the
>>> physical address.
>> You are probably correct but I don't work with AMD processors
>> and don't understand their requirements. If someone
>> wants to submit a patch to support larger phys memory sizes,
>> I certainly have no objections....
>
> The only advantage 44 bits has over 48 bits is that it allows us to 
> uniquely identify 4k physical pages with 32 bits, potentially allowing for 
> tighter packing of certain structures.  Do we have any code that does this, 
> and if so, is it a worthwhile optimization?

I've checked where those defines are used. If I didn't miss something
MAX_PHYSADDR_BITS isn't used at all on x86 and MAX_PHYSMEM_BITS is
used (directly or indirectly) in several other macros.

But basically it's just section_to_node_table which would increase to 2
or 4 MB depending on MAX_NUMNODES.  Using 44 bits this table is just
128 kB resp. 256 kB in size.

> Personally, I think we should support the full capability of the hardware, 
> but I don't have a 17 TB Opteron box to test with.

I don't have one either.
By adjusting some NB-registers it might be possible to configure
physical addresses larger than 40 or 44 bits though. (Even if the
machine has not more than 1 or 16 TB.) I'll verify whether this is
really possible.

At the moment I think it's best to leave the define as is (44 or 40
bit) as there is currently no practical benefit from increasing it to
48 bit.


Regards,

Andreas


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