From: Andreas Herrmann <andreas.herrmann3@amd.com>
To: Chris Snook <csnook@redhat.com>
Cc: Jack Steiner <steiner@sgi.com>,
mingo@elte.hu, ak@suse.de, tglx@linutronix.de,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] - Increase max physical memory size of x86_64
Date: Thu, 27 Mar 2008 18:30:27 +0100 [thread overview]
Message-ID: <20080327173027.GA26969@alberich.amd.com> (raw)
In-Reply-To: <47E96876.3050206@redhat.com>
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
next prev parent reply other threads:[~2008-03-27 18:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-21 13:31 [PATCH] - Increase max physical memory size of x86_64 Jack Steiner
2008-03-21 14:24 ` Ingo Molnar
2008-03-25 16:41 ` Andreas Herrmann
2008-03-25 16:54 ` Jack Steiner
2008-03-25 21:02 ` Chris Snook
2008-03-27 17:30 ` Andreas Herrmann [this message]
2008-03-27 17:55 ` Jack Steiner
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=20080327173027.GA26969@alberich.amd.com \
--to=andreas.herrmann3@amd.com \
--cc=ak@suse.de \
--cc=csnook@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@elte.hu \
--cc=steiner@sgi.com \
--cc=tglx@linutronix.de \
/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