Bug 470351 - FEAT RHEL6 (1383): Support for systems with 46 bits of (physical) address space during the lifespan of RHEL6
FEAT RHEL6 (1383): Support for systems with 46 bits of (physical) address spa...
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity high
: alpha
: 6.0
Assigned To: Rik van Riel
Eryu Guan
: FutureFeature
: 469905 (view as bug list)
Depends On:
Blocks: 451296 451287 464272 519883 554559 555224 555228 581929
  Show dependency treegraph
Reported: 2008-11-06 14:57 EST by Adaora Onyia
Modified: 2010-11-10 15:47 EST (History)
21 users (show)

See Also:
Fixed In Version: kernel-2.6.32-12.el6
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
: 581929 (view as bug list)
Last Closed: 2010-11-10 15:47:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Adaora Onyia 2008-11-06 14:57:05 EST
1.  Feature Overview:
     a. Name of feature:
        See Summary

     b. Feature Description
        In the RHEL6 lifespan need support for systems with 48 bits of(physical) address space.

2.  Feature Details:
     a. Architectures:
         64-bit Intel EM64T/AMD64
         64-bit Itanium2
     b. Bugzilla Dependencies:
        (Are there other RHEL 6 bugzillas that this bug depends on?)

     c. Drivers or hardware dependencies:
        (Are there updated driver versions required?)
        (When will Red Hat receive test hardware if applicable?)

     d. Upstream acceptance information:
        (When was this accepted upstream, or when will this be submitted

     e. External links:
        (Are there links to committed upstream patches?)

     f. Severity (U,H,M,L):
         High (required for Hardware Enablement)

     g. Target Release Date:

3. Business Justification:
     a. Why is this feature needed?
hardware enablement
     b. What hardware does this enable?
     c. Forecast, impact on revenue?
        (include high/low volume with high/low-end platform info)
     d. Any configuration info?
     e. Are there other dependencies (drivers).

4. Primary contact at Red Hat, email, phone (chat)
    Ron Pacheco

5. Primary contact at Partner, email, phone (chat)
    Adaora Onyia
Comment 1 Rik van Riel 2009-03-31 08:36:09 EDT
48 bits physical / 48 bits virtual is unlikely to ever happen on x86-64.

The reason is that x86-64 does not have highmem (thank god!), which means the kernel always needs to have all of physical memory mapped into its address space. What is left over of address space can be used for userspace, vmalloc space and hypervisor address space.

This means that with 48 bits virtual address space, x86-64 is unlikely to support more than 46 bits of physical address space. Even going to 46 bits physical might require some changes in the x86-64 kernel memory layout...
Comment 2 John Villalovos 2009-04-10 11:04:44 EDT
Comment from one of our Intel engineers, concerning upstream Linux kernel:
Specifically - without changing the virtual address space, we can do:

- 45 bits with minimal effort
- 46 bits with a modicum of effort
- 47 or more -- forget it

Again, this does apply to RAM space only.  I/O only physical address space is not affected by this limitation, although if that I/O space is actually *populated* (and needs to be mapped) then it does add into the equation again.
Comment 3 John Villalovos 2009-04-13 13:12:57 EDT

Are you willing to help Intel test 45 and or 46 bit physical support?  Currently the upstream kernel supports 44 bits of physical memory and we would need some way to test higher bit counts than that.

John - Intel engineer onsite at Red Hat
Comment 4 Adaora Onyia 2009-04-16 02:58:12 EDT
HP will be willing to help with the testing but needs to understand what the testing will entail.  Baeed on comment #2, support for 48 bits of physical address space during the lifespan of RHEL6 is not possible meaning that this feature request may end up being closed or with drawn.
Comment 5 Ronald Pacheco 2009-04-16 09:19:49 EDT

Please note that this is an upstream limit that affects all distros, not just Red Hat.  That aside, 44-bit addressing will yield 16 TB support.  Does HP have an interest in support up to 16 TB?
Comment 6 Ronald Pacheco 2009-04-21 13:39:57 EDT
*** Bug 469905 has been marked as a duplicate of this bug. ***
Comment 7 Adaora Onyia 2009-04-22 03:27:08 EDT
Yes, HP will have interest in 16TB support at some point during the lifespan of RHEL6.
Comment 8 Rik van Riel 2009-04-29 15:12:44 EDT
http://lkml.org/lkml/2008/12/16/291 has the TODO list.
Comment 13 Rik van Riel 2009-05-05 17:43:32 EDT
I have just posted a patch for 46 bit PAE support upstream:


I will continue pushing and revising the patch as required.
Comment 14 Rik van Riel 2009-05-06 10:44:19 EDT
The patch got applied to tip and will probably make it upstream in the next merge window:

Comment 15 Chris Ward 2009-11-25 05:09:48 EST

We need to confirm that there is third-party commitment to 
test for the resolution of this request during the RHEL 6.0 
Beta Test Phase before we can approve it for acceptance 
into the release.

In order to avoid any unnecessary delays, please post a 
confirmation as soon as possible, including the contact 
information for testing engineers.

Any additional information about alternative testing variations we 
could use to reproduce this issue in-house would be appreciated.
Comment 18 Adaora Onyia 2009-12-03 17:04:18 EST
BCS will commit to testing this.
Comment 20 Rik van Riel 2010-01-14 13:43:18 EST
Yes, this patch has been upstream for a bit.
Comment 35 releng-rhel@redhat.com 2010-11-10 15:47:43 EST
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.

Note You need to log in before you can comment on or make changes to this bug.