From: David Miller <davem@davemloft.net>
To: torvalds@linux-foundation.org
Cc: arjan@infradead.org, mingo@elte.hu, nickpiggin@yahoo.com.au,
sqazi@google.com, linux-kernel@vger.kernel.org,
tglx@linutronix.de, hpa@zytor.com, andi@firstfloor.org
Subject: Re: [patch] x86, mm: pass in 'total' to __copy_from_user_*nocache()
Date: Sat, 28 Feb 2009 16:06:51 -0800 (PST) [thread overview]
Message-ID: <20090228.160651.228301019.davem@davemloft.net> (raw)
In-Reply-To: <alpine.LFD.2.00.0902280935010.3111@localhost.localdomain>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sat, 28 Feb 2009 09:42:18 -0800 (PST)
> On Sat, 28 Feb 2009, Arjan van de Ven wrote:
> >
> > it invalidates all caches in the hierarchy
>
> Yeah, now that I look at the intel pdf's, I see that.
>
> > afaik this is what Intel cpus do; but I also thought this behavior was
> > quite architectural as well...
>
> Ok, I really think we should definitely not use non-temporal stores for
> anything smaller than one full page in that case. In fact, I wonder if
> even any of the old streaming benchmarks are even true. I thought it would
> still stay in the L3, but yes, it literally seems to make the access
> totally noncached and WC.
>
> That's almost unacceptable in the long run. With a 8MB L3 cache - and a
> compile sequence, do we really want to go out to memory to write the .S
> file, and then have the assembler go out to memory to read it back? For a
> compile, that _probably_ is all fine (the compiler in particular will have
> enough data structures around that it's not going to fit in the cache
> anyway), but I'm seeing leaner compilers and other cases where forcing
> things out all the way on the bus is simply the wrong thing.
I think this is an accurate analysis as well, it's really unfortunate
the non-temporal stuff on x86 doesn't preserve existing cache lines
when present.
I thought that was the whole point. Don't pollute the caches, but
if cache lines are already loaded there, use them and don't purge!
next prev parent reply other threads:[~2009-03-01 0:07 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-24 2:03 Performance regression in write() syscall Salman Qazi
2009-02-24 4:10 ` Nick Piggin
2009-02-24 4:28 ` Linus Torvalds
2009-02-24 9:02 ` Nick Piggin
2009-02-24 15:52 ` Linus Torvalds
2009-02-24 16:24 ` Andi Kleen
2009-02-24 16:51 ` Ingo Molnar
2009-02-25 3:23 ` Nick Piggin
2009-02-25 7:25 ` [patch] x86, mm: pass in 'total' to __copy_from_user_*nocache() Ingo Molnar
2009-02-25 8:09 ` Nick Piggin
2009-02-25 8:29 ` Ingo Molnar
2009-02-25 8:59 ` Nick Piggin
2009-02-25 12:01 ` Ingo Molnar
2009-02-25 16:04 ` Linus Torvalds
2009-02-25 16:29 ` Ingo Molnar
2009-02-27 12:05 ` Nick Piggin
2009-02-28 8:29 ` Ingo Molnar
2009-02-28 11:49 ` Nick Piggin
2009-02-28 12:58 ` Ingo Molnar
2009-02-28 17:16 ` Linus Torvalds
2009-02-28 17:24 ` Arjan van de Ven
2009-02-28 17:42 ` Linus Torvalds
2009-02-28 17:53 ` Arjan van de Ven
2009-02-28 18:05 ` Andi Kleen
2009-02-28 18:27 ` Ingo Molnar
2009-02-28 18:39 ` Arjan van de Ven
2009-03-02 10:39 ` [PATCH] x86, mm: dont use non-temporal stores in pagecache accesses Ingo Molnar
2009-02-28 18:52 ` [patch] x86, mm: pass in 'total' to __copy_from_user_*nocache() Linus Torvalds
2009-03-01 14:19 ` Nick Piggin
2009-03-01 0:06 ` David Miller [this message]
2009-03-01 0:40 ` Andi Kleen
2009-03-01 0:28 ` H. Peter Anvin
2009-03-01 0:38 ` Arjan van de Ven
2009-03-01 1:48 ` Andi Kleen
2009-03-01 1:38 ` Arjan van de Ven
2009-03-01 1:40 ` H. Peter Anvin
2009-03-01 14:06 ` Nick Piggin
2009-03-02 4:46 ` H. Peter Anvin
2009-03-02 6:18 ` Nick Piggin
2009-03-02 21:16 ` Linus Torvalds
2009-03-02 21:25 ` Ingo Molnar
2009-03-03 4:30 ` Nick Piggin
2009-03-03 4:20 ` Nick Piggin
2009-03-03 9:02 ` Ingo Molnar
2009-03-04 3:37 ` Nick Piggin
2009-03-01 2:07 ` Andi Kleen
2009-02-24 5:43 ` Performance regression in write() syscall Salman Qazi
2009-02-24 10:09 ` Andi Kleen
2009-02-24 16:13 ` Ingo Molnar
2009-02-24 16:51 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090228.160651.228301019.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=andi@firstfloor.org \
--cc=arjan@infradead.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=nickpiggin@yahoo.com.au \
--cc=sqazi@google.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome