Messages in this thread | | | Date | Wed, 8 Dec 2010 15:22:44 -0600 | From | Jack Steiner <> | Subject | Re: [RFC - V2] - Mapping ACPI tables as CACHED |
| |
On Thu, Aug 26, 2010 at 11:08:02AM -0700, H. Peter Anvin wrote: > On 08/26/2010 10:17 AM, Jack Steiner wrote: > > Map ACPI tables as WB on x86_64. No substantive changes to IA64. > > > > > > Signed-off-by: Jack Steiner <steiner@sgi.com> > > > > --- > > V2 - Change the patch to unconditionally map ACPI tables as WB on x86_64. > > I'm still some paranoid about this because of the potential imapct on > > some platforms with weird BIOSs. However, note that on EFI-enabled > > systems (like UV), the ACPI tables are already mapped as WB memory. > > This is done in the EFI function efi_enter_virtual_mode(). > > The ACPI code in acpi_os_map_memory() is not currently aware of the > > EFI mapping & currently maps the memory as UC. This seems like a bug. > > > > I really think that it's all a consequence of the fact that ioremap() > became implicitly UC when we added PAT support (being the more > conservative choice.) > > Len, want to take this one or should I? > > -hpa
What is the upstream status of this patch? See the LKML discussion at:
http://marc.info/?l=linux-kernel&m=128206079905826&w=2 http://marc.info/?l=linux-acpi&m=128284304032481&w=2
We would like to get this patch into the distros but need upstream acceptance first.
This patch substantially reduces the time to run ACPIDUMP on a large system: 527 seconds without the patch 8 seconds with the patch
Is there something I should be doing? I can resend the patch if needed.
--- jack
| |