From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Ingo Molnar <mingo@elte.hu>,
Arjan van de Ven <arjan@infradead.org>,
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: Mon, 2 Mar 2009 01:19:33 +1100 [thread overview]
Message-ID: <200903020119.34455.nickpiggin@yahoo.com.au> (raw)
In-Reply-To: <alpine.LFD.2.00.0902281041160.3111@localhost.localdomain>
On Sunday 01 March 2009 05:52:19 Linus Torvalds wrote:
> On Sat, 28 Feb 2009, Ingo Molnar wrote:
> > OTOH, given how draconian non-temporal stores are, i'm leaning
> > towards removing them from the x86 code altogether. If it matter
> > to performance somewhere it can be reintroduced, based on really
> > well backed up numbers.
>
> It would be interesting to see if we could instead base the decision on
> what we really do care about, namely going to do IO.
>
> And the thing is, in this path we _do_ kind of know that. The caller
> (normally generic_perform_write) already does that whole
> balance_dirty_pages_ratelimited() thing.
>
> So rather than passing in the "total_size" thing, we _could_ pass in
> something that is based on
>
> - are we O_DIRECT? If so: use uncached
Zero copies in that case :) O_SYNC, you mean.
> - perhaps: are we really _really_ large? If so: use uncached, we know the
> caches aren't going to capture it.
But how large, and which caches? I wouldn't expect very many apps at all
to pass buffers larger than even quite small LLC sizes.
> - are we starting writeout due to dirty page balancing: if so, use
> uncached.
Although that should tend to write out oldest written data, wheras
the newly written data might still benefit from being warm in cache
(eg. in the cpp|cc|as|ld case).
> But on the other hand, I could personally certainly also imagine just not
> doing that whole uncached thing at all. Myself, I tend to care about the
> peformance of the cached case much more than some odd iozone thing. But
> others will have different priorities..
FWIW I agree with you. rep mov I think gives the CPU a good window into
proceedings and usually should do a good job.
next prev parent reply other threads:[~2009-03-01 14:20 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 [this message]
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=200903020119.34455.nickpiggin@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=andi@firstfloor.org \
--cc=arjan@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.