lkml.org 
[lkml]   [2010]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC] - Mapping ACPI tables as CACHED
From
Date
On Fri, 2010-07-23 at 15:23 +0800, Ingo Molnar wrote:
> * ykzhao <yakui.zhao@intel.com> wrote:
>
> > From the above description maybe the E820_ACPI region can be mapped as
> > cached. But this still depends on the BIOS. If the some shared data resides
> > in the E820_ACPI region on some BIOS, maybe we can't map the E820_ACPI
> > region as cached again.
>
> I dont think we can do this safely unless some other OS (Windows) does it as
> well. (the reason is that if some BIOS messes this up then it will cause nasty
> bugs/problems only on Linux.)
>

Yes. We can't map the corresponding ACPI region as cached under the
following case:
>No E820_ACPI region is reported by BIOS. In such case the ACPI
table resides in the NVS region

But if the BIOS can follow the spec and report the separated
E820_ACPI/E820_NVS region, maybe we can give a try to map the E820_ACPI
region as cached type. For example: the server machine.(The spec
describes the E820_ACPI region as reclaimed memory, which means that it
can be managed by OS after ACPI table is loaded).

Can we add a boot option to control whether the E820_ACPI region can be
mapped as cached type?

> But the benefits of caching are very clear and well measured by Jack, so we
> want the feature. What we can do is to add an exception for 'known good' hw
> vendors - i.e. something quite close to Jack's RFC patch, but implemented a
> bit more cleanly:
>
> Exposing x86_platform and e820 details to generic ACPI code isnt particularly
> clean - there should be an ACPI accessor function for that or so: a new
> acpi_table_can_be_cached(table) function or so.

Agree. The function of acpi_os_map_memory will also be used on IA64
platform. It seems more reasonable to use a wrapper function to check
whether the corresponding region can be mapped as cached type.
>
> In fact since __acpi_map_table(addr,size) is defined by architectures already,
> this could be done purely within x86 code.
>
> Thanks,
>
> Ingo



\
 
 \ /
  Last update: 2010-07-23 16:33    [from the cache]
©2003-2011 Jasper Spaans