Re: [PATCH v5] x86: Enable fast strings on Intel if BIOS hasn't already

[Andy Lutomirski]

On Wed, May 1, 2013 at 10:35 AM, H. Peter Anvin <hpa@xxxxxxxxx> wrote:
> On 05/01/2013 09:54 AM, Andy Lutomirski wrote:
>>
>> (Just my luck.  I'm currently trying to implement WT via PAT by
>> stealing a slot from either UC or UC-.)
>>
>
> NAK on that.  Use a slot in the upper half, perhaps (we already
> blacklist the CPUs for which the upper half aren't usable.)

Isn't the upper half incompatible with large pages?

Why the NAK?  Unless I've misread the spec, UC and UC- are only
different if there's a WC MTRR set, and I haven't found anything in
the kernel yet that adds a WC MTRR that actually needs that MTRR if
PAT is enabled.  I've made my way about half-way through the mtrr_add
calls so far.  (The drivers that use MTRRs are graphics devices, ivtv,
fusion MPT, myri10ge, and infiniband.)

>
> What do you want WT for, anyway?

Generically, memory regions in which writes have side effects but
reads are just reads and should be cached.

In particular, persistent (i.e. nonvolatile) memory.  There's an NDA
involved, but I can safely say (at least): there seem to be nifty
devices that aren't quite RAM that are nonetheless presented to the
system as RAM.  Write are durable, but only if they make it out of
cache before power fails or the CPU resets in such a way that caches
are invalidated but not written back.  UC and WC are a bit
heavy-handed because read caching is fine.  (PowerPC has nice
instructions for things like "write this back now", but x86 seems to
be missing any way other than WT to force data out to RAM without
invalidating the cache line.)

Making this work with a WT MTRR is probably doable, but it's IMO
rather ugly.  Even if I go that route, I'd still want to convince
graphics drivers to stop wasting MTRRs, since they don't need them and
they tend to be in short supply.

Here's an example:

http://www.tomshardware.com/news/Viking-ArxCis-NV-NVDIMM-RAM,21892.html


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