lkml.org 
[lkml]   [2009]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2009-02-28 18:27    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site