linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nick Piggin <npiggin@suse.de>
To: Denys Vlasenko <vda.linux@googlemail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Andi Kleen <andi@firstfloor.org>,
	Jens Axboe <jens.axboe@oracle.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-fsdevel@vger.kernel.org,
	Ravikiran G Thirumalai <kiran@scalex86.org>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [rfc][patch] store-free path walking
Date: Fri, 9 Oct 2009 09:47:19 +0200	[thread overview]
Message-ID: <20091009074719.GE2983@wotan.suse.de> (raw)
In-Reply-To: <1158166a0910080612h29d93d50y875d5305cd4d985f@mail.gmail.com>

On Thu, Oct 08, 2009 at 03:12:08PM +0200, Denys Vlasenko wrote:
> On Wed, Oct 7, 2009 at 11:57 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > This, btw, is exactly the kind of thing we saw with some of the
> > non-temporal work, when we used nontemporal stores to copy pages on COW
> > faults, or when doing pre-zeroing of pages. You get rid of some of the
> > hot-spots in the kernel, and you then replace them with user space taking
> > the cache misses in random spots instead. The kernel profile looks better,
> > and system time may go down, but actual performace never went down - you
> > just moved your cache miss cost from one place to another.
> 
> A few years ago when K7s were not ancient yet, after hearing
> argument for and against non-temporal stores,
> I decided to finally figure it for myself.
> 
> I tested kernel build workload on two kernels with the only
> one difference - clear_page with and without non-temporal stores.
> 
> "Non-temporal stores" kernel was faster, not slower. Just a little bit,
> but reproducibly.

It is going to be highly dependent on architecture and workload and
exactly where you use the nontemporal stores of course. I would say
with non-temporal stores in clear_page (a case where we can often
expect the memory to be used again quickly because it is anonymous
process memory), then we are quite likely to cause _more_ activity
on the memory controller and dimms which cost far more power than
cache access.


  reply	other threads:[~2009-10-09  7:47 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-06  6:49 Latest vfs scalability patch Nick Piggin
2009-10-06 10:14 ` Jens Axboe
2009-10-06 10:26   ` Jens Axboe
2009-10-06 11:10     ` Peter Zijlstra
2009-10-06 12:51       ` Jens Axboe
2009-10-06 12:26   ` Nick Piggin
2009-10-06 12:49     ` Jens Axboe
2009-10-07  8:58       ` [rfc][patch] store-free path walking Nick Piggin
2009-10-07  9:56         ` Jens Axboe
2009-10-07 10:10           ` Nick Piggin
2009-10-12  3:58           ` Nick Piggin
2009-10-12  5:59             ` Nick Piggin
2009-10-12  8:20               ` Jens Axboe
2009-10-12 11:00                 ` Jens Axboe
2009-10-13  1:26             ` Christoph Hellwig
2009-10-13  1:52               ` Nick Piggin
2009-10-07 14:56         ` Linus Torvalds
2009-10-07 16:27           ` Linus Torvalds
2009-10-07 16:46             ` Nick Piggin
2009-10-07 19:25               ` Linus Torvalds
2009-10-07 20:34                 ` Andi Kleen
2009-10-07 20:51                   ` Linus Torvalds
2009-10-07 21:06                     ` Andi Kleen
2009-10-07 21:20                       ` Linus Torvalds
2009-10-07 21:57                         ` Linus Torvalds
2009-10-07 22:22                           ` Andi Kleen
2009-10-08  7:39                             ` Nick Piggin
2009-10-09 17:53                               ` Andi Kleen
2009-10-08 13:12                           ` Denys Vlasenko
2009-10-09  7:47                             ` Nick Piggin [this message]
2009-10-09 17:49                             ` Andi Kleen
2009-10-07 16:29           ` Nick Piggin
2009-10-08 12:36           ` Nick Piggin
2009-10-08 12:57             ` Jens Axboe
2009-10-08 13:22               ` Nick Piggin
2009-10-08 13:30                 ` Jens Axboe
2009-10-08 18:00                   ` Peter Zijlstra
2009-10-09  4:04                     ` Nick Piggin
2009-10-09  8:54                 ` Jens Axboe
2009-10-09  9:51                   ` Jens Axboe
2009-10-09 10:02                     ` Nick Piggin
2009-10-09 10:08                       ` Jens Axboe
2009-10-09 10:07                   ` Nick Piggin
2009-10-09  3:50             ` Nick Piggin
2009-10-09  6:15               ` David Miller
2009-10-09 10:40                 ` Nick Piggin
2009-10-09 11:09                   ` Jens Axboe
2009-10-09 10:44                 ` Nick Piggin
2009-10-09 10:48                   ` Jens Axboe
2009-10-09 23:16         ` Paul E. McKenney
2009-10-15 10:08 ` Latest vfs scalability patch Anton Blanchard
2009-10-15 10:39   ` Nick Piggin
2009-10-15 10:46     ` Anton Blanchard
2009-10-15 10:53   ` Nick Piggin
2009-10-15 11:23     ` Anton Blanchard
2009-10-15 11:41       ` Nick Piggin
2009-10-15 11:48         ` Nick Piggin

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=20091009074719.GE2983@wotan.suse.de \
    --to=npiggin@suse.de \
    --cc=andi@firstfloor.org \
    --cc=jens.axboe@oracle.com \
    --cc=kiran@scalex86.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.org \
    --cc=vda.linux@googlemail.com \
    /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;
as well as URLs for NNTP newsgroup(s).