linux-kernel - Re: [RFC] - Mapping ACPI tables as CACHED

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTinM7U-Vb0h5De9W54mHkBby7LZNztxLLQ=HuYdh@mail.gmail.com>
Date:	Tue, 17 Aug 2010 09:02:21 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jack Steiner <steiner@....com>
Cc:	Henrique de Moraes Holschuh <hmh@....eng.br>, mingo@...e.hu,
	tglx@...utronix.de, lenb@...nel.org, linux-acpi@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC] - Mapping ACPI tables as CACHED

On Tue, Aug 17, 2010 at 7:49 AM, Jack Steiner <steiner@....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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/