linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2008-03-27 17:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-21 13:31 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