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

[Ingo Molnar <mingo@kernel.org>]

* Andy Lutomirski <luto@amacapital.net> wrote:

> > 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

This looks potentially useful.

I'd consider your cache-attributes review and cleanups to drivers and 
infrastructure to be the main upstream benefit we win from your effort.

So as long as your patches go in that general direction, and the PAT code 
and its usage gets cleaner and more organized, and there's no showstopper 
issue discovered, the fact that you gain ioremap_wt() for your driver is 
mostly just a happy coincidence that we don't mind that much.

Maybe in the end we'd have to hide it behind some sort of 
CONFIG_COMPAT_PAT trigger and turn it off on old/buggy systems - but in 
the first approximation it would be nice to try and make this just a 
single variant with no Kconfig complexity?

Thanks,

	Ingo