Messages in this thread | | | Date | Sat, 28 Feb 2009 09:24:50 -0800 | From | Arjan van de Ven <> | Subject | Re: [patch] x86, mm: pass in 'total' to __copy_from_user_*nocache() |
| |
On Sat, 28 Feb 2009 09:16:21 -0800 (PST) Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > > On Sat, 28 Feb 2009, Ingo Molnar wrote: > > > > Can you suggest some other workload that should show sensitivity > > to this detail too? Like a simple write() loop of non-4K-sized > > files or so? > > I bet you can find it, but I also suspect that it will depend quite a > bit on the microarchitecture. What does 'movntq' actually _do_ on > different CPU's (bypass L1 or L2 or just turn the L1 cache policy to > "write through and invalidate")?
Afaik it's like a cache flush followed by the equivalent of a WC store
> How expensive is the sfence when > there are still stores in the write buffer? Does 'movqnt' even use > the write buffer for cached stores, or is doing some special path the > the last-level cache?
it's usually like a WC store > > If you want to be really subtle, ask questions like what are the > implications for last-level caches that are inclusive? The last-level > cache would take not just the new write, but it also has logic to > make sure that it's a superset of the inner caches, so what does that > do to replacement policy for that cache? Or does it cause > invalidations in the inner caches?
it invalidates all caches in the hierarchy
afaik this is what Intel cpus do; but I also thought this behavior was quite architectural as well...
-- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org
| |