Red Hat Bugzilla – Bug 470351
FEAT RHEL6 (1383): Support for systems with 46 bits of (physical) address space during the lifespan of RHEL6
Last modified: 2010-11-10 15:47:43 EST
1. Feature Overview:
a. Name of feature:
b. Feature Description
In the RHEL6 lifespan need support for systems with 48 bits of(physical) address space.
2. Feature Details:
64-bit Intel EM64T/AMD64
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?
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)
5. Primary contact at Partner, email, phone (chat)
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 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.
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
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.
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?
*** Bug 469905 has been marked as a duplicate of this bug. ***
Yes, HP will have interest in 16TB support at some point during the lifespan of RHEL6.
http://lkml.org/lkml/2008/12/16/291 has the TODO list.
I have just posted a patch for 46 bit PAE support upstream:
I will continue pushing and revising the patch as required.
The patch got applied to tip and will probably make it upstream in the next merge window:
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.
BCS will commit to testing this.
Yes, this patch has been upstream for a bit.
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.