From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Ingo Molnar <mingo@elte.hu>, Salman Qazi <sqazi@google.com>,
davem@davemloft.net, linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
Andi Kleen <andi@firstfloor.org>
Subject: Re: [patch] x86, mm: pass in 'total' to __copy_from_user_*nocache()
Date: Fri, 27 Feb 2009 23:05:00 +1100 [thread overview]
Message-ID: <200902272305.01867.nickpiggin@yahoo.com.au> (raw)
In-Reply-To: <alpine.LFD.2.00.0902250753030.3111@localhost.localdomain>
On Thursday 26 February 2009 03:04:22 Linus Torvalds wrote:
> On Wed, 25 Feb 2009, Ingo Molnar wrote:
> > The main artifact would be the unaligned edges around a bigger
> > write. In particular the tail portion of a big write will be
> > cached.
>
> .. but I don't really agree that this is a problem.
>
> Sure, it's "wrong", but does it actually matter? No. Is it worth adding
> complexity to existing interfaces for? I think not.
>
> In general, I think that software should not mess with nontemporal stores.
> The thing is, software almost never knows enough about the CPU cache to
> make an intelligent choice.
>
> So I didn't want to apply the nocache patches in the first place, but the
> performance numbers were pretty clear. I'll take "real numbers" over my
> personal dislikes any day. But now we have real numbers going the other
> way for small writes, and a patch to fix that.
>
> But we have no amount of real numbers for the edge cases, and I don't
> think they matter. In fact, I don't think they _can_ matter, because it is
> inevitably always going to be an issue of "which CPU and which memory
> subsystem".
>
> In other words, there is no "right" answer. There is no "perfect". But
> there is "we can fix the real numbers".
Well... these are "real" benchmark numbers. Where the benchmark is
actually apparently performing an access pattern that seemingly
should favour nontemporal stores (the numbers are just measuring the
phase were write(2) is being done).
> At the same time, we also do know:
> - caches work
> - CPU designers will continue to worry about the normal (cached) case,
> and will do reasonable things with cache replacement.
> - ergo: w should always consider the cached case to be the _normal_ mode,
> and it's the nontempral loads/stores that need to explain themselves.
>
> So I do think we should just apply the simple patch. Not make a big deal
> out of it. We have numbers. We use cached memory copies for everything
> else. It's always "safe".
>
> And we pretty much know that the only time we will ever really care about
> the nontemporal case is with big writes - where the "edge effects"
> essentially become total noise.
I guess so. I wouldn't mind just doing cached stores all the time for
the reasons you say.
But whatever. If it ever becomes *really* important, I guess we can flag
this kind of behaviour from userspace.
next prev parent reply other threads:[~2009-02-27 12:05 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 [this message]
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
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=200902272305.01867.nickpiggin@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=andi@firstfloor.org \
--cc=davem@davemloft.net \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--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