lkml.org 
[lkml]   [2010]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [RFC] - Mapping ACPI tables as CACHED
On Tue, Aug 17, 2010 at 7:49 AM, Jack Steiner <steiner@sgi.com> wrote:
>
> I'm certainly not suggesting that ALL platforms map ACPI tables as WB. That
> would be a disaster. Only platforms where BIOS specifically reports that
> that tables are in WB memory should be mapped as MB.

Hmm. I actually suspect we _should_ map ACPI tables as WB all the
time. I'm not actually seeing any reason why we should ever map them
uncacheable, because as far as I can tell there are exactly two
realistic situations:

- they are in RAM to begin with. I would pretty much expect this to
be true 99.9% of the time. Everybody uses compressed BIOS flash images
and uncompresses the image into RAM anyway, because (a) bigger flash
chips are another 25¢, so nobody can afford that on a PC motherboard
(b) the flash interface is ridiculously slow anyway, and you don't
want to execute your BIOS off it, and (c) the BIOS almost always
actually _changes_ the tables depending on various BIOS settings, so
mapping the tables as anything but RAM wouldn't work _anyway_.

- even if they aren't in RAM, it's likely fine to let the dang things
be in the cache. On at least some platforms (old ones), if they aren't
in RAM, the system logic will override any MTRR/pageattribute issues
anyway.

So I think we should just map those things WB by default. Maybe with
some way to override it (possibly automatically). It sounds like it's
a big enough performance issue even on smaller systems (0.1 seconds is
quite a bit of the boot time on some systems).

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2010-08-17 18:05    [W:0.097 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site