Bug 470351

Summary: FEAT RHEL6 (1383): Support for systems with 46 bits of (physical) address space during the lifespan of RHEL6
Product: Red Hat Enterprise Linux 6 Reporter: Adaora Onyia <adaora.onyia>
Component: kernelAssignee: Rik van Riel <riel>
Status: CLOSED CURRENTRELEASE QA Contact: Eryu Guan <eguan>
Severity: high Docs Contact:
Priority: medium    
Version: 6.0CC: adaora.onyia, bjorn.helgaas, bzeranski, cward, dwu, eguan, emcnabb, jane.lv, jlv, jvillalo, kzhang, luyu, lwoodman, mingo, myron.stowe, ndai, pzijlstr, rdoty, riel, rpacheco, snagar
Target Milestone: alphaKeywords: FutureFeature
Target Release: 6.0   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: kernel-2.6.32-12.el6 Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
: 581929 (view as bug list) Environment:
Last Closed: 2010-11-10 20:47:43 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 451287, 451296, 464272, 519883, 554559, 555224, 555228, 581929    

Description Adaora Onyia 2008-11-06 19:57:05 UTC
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
         upstream?)

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

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

     g. Target Release Date:
        TBD


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
    rpacheco


5. Primary contact at Partner, email, phone (chat)
    Adaora Onyia
    adaora.onyia
    970-898-0715

Comment 1 Rik van Riel 2009-03-31 12:36:09 UTC
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 15:04:44 UTC
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 17:12:57 UTC
HP,

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.

Thanks,
John - Intel engineer onsite at Red Hat

Comment 4 Adaora Onyia 2009-04-16 06:58:12 UTC
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 13:19:49 UTC
Adaora,

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 17:39:57 UTC
*** Bug 469905 has been marked as a duplicate of this bug. ***

Comment 7 Adaora Onyia 2009-04-22 07:27:08 UTC
Yes, HP will have interest in 16TB support at some point during the lifespan of RHEL6.

Comment 8 Rik van Riel 2009-04-29 19:12:44 UTC
http://lkml.org/lkml/2008/12/16/291 has the TODO list.

Comment 13 Rik van Riel 2009-05-05 21:43:32 UTC
I have just posted a patch for 46 bit PAE support upstream:

http://marc.info/?l=linux-kernel&m=124155907718521&w=2

I will continue pushing and revising the patch as required.

Comment 14 Rik van Riel 2009-05-06 14:44:19 UTC
The patch got applied to tip and will probably make it upstream in the next merge window:

http://git.kernel.org/tip/c898faf91b3ec6b0f6efa35831b3984fa3331db0

Comment 15 Chris Ward 2009-11-25 10:09:48 UTC
@Reporters

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 22:04:18 UTC
BCS will commit to testing this.

Comment 20 Rik van Riel 2010-01-14 18:43:18 UTC
Yes, this patch has been upstream for a bit.

Comment 35 releng-rhel@redhat.com 2010-11-10 20:47:43 UTC
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.