All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Dave Hansen <dave@linux.vnet.ibm.com>,
	Nick Piggin <nickpiggin@yahoo.com.au>,
	Salman Qazi <sqazi@google.com>,
	linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Andi Kleen <andi@firstfloor.org>,
	Dave Hansen <haveblue@us.ibm.com>
Subject: Re: Another Performance Regression in write() syscall
Date: Tue, 24 Feb 2009 18:50:55 +0100	[thread overview]
Message-ID: <20090224175055.GA14534@elte.hu> (raw)
In-Reply-To: <alpine.LFD.2.00.0902240924490.3111@localhost.localdomain>


* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Tue, 24 Feb 2009, Dave Hansen wrote:
> > 
> > Yeah, that's a good point.  Are we sure that's what is 
> > happening here, though?  That's one thing a profile would 
> > hopefully help with.
> 
> One thing to note is that _if_ it's purely an issue of 
> nontemporal stores vs normal stores, then profiling is very 
> likely going to be almost entirely useless. You'll get 
> "results", but the results have nothing what-so-ever to do 
> with reality or anything interesting.
> 
> The nontemporal stores may stand out in the profiles, but the 
> actual performance impact will be all about whether totally 
> unrelated code got cache misses or not. Quite often those 
> cache misses will also be in user mode, and very possibly in 
> other processes.
> 
> So profiles can certainly be interesting, but if Salman says 
> that his patch makes a difference for his benchmark, then 
> profiling is almost certainly not interesting FOR THAT PATCH. 
> It's interesting mainly as a way to look at whether there are 
> then also _other_ issues that are worth addressing (ie the 
> whole atime thing is in a whole different dimension and an 
> independent issue).

a 'perfstat' run would certainly be interesting (for cases where 
a pure /usr/bin/time run is inconclusive), comparing the 
unpatched and patched kernel.

That way we can see summary counts for the whole workload, like:

 -----------------------------------------------
 | Performance counter stats for './mmap-perf' |
 -----------------------------------------------
 |                |
 |  x86-defconfig |   PARAVIRT=y
 |------------------------------------------------------------------
 |
 |    1311.554526 |  1360.624932  task clock ticks (msecs)    +3.74%
 |                |
 |              1 |            1  CPU migrations
 |             91 |           79  context switches
 |          55945 |        55943  pagefaults
 |    ............................................
 |     3781392474 |   3918777174  CPU cycles                  +3.63%
 |     1957153827 |   2161280486  instructions               +10.43%
 |       50234816 |     51303520  cache references            +2.12%
 |        5428258 |      5583728  cache misses                +2.86%
 |
 |      437983499 |    478967061  branches                    +9.36%
 |       32486067 |     32336874  branch-misses               -0.46%
 |                |
 |    1314.782469 |  1363.694447  time elapsed (msecs)        +3.72%
 |                |
 -----------------------------------

Such a comparison of would certainly be more meaningful for such 
things than a profile.

Salman, if you are interested in doing a perfstat comparison, 
just pick up a tip:master kernel [perfcounters are 
default-enabled in it]:

   http://people.redhat.com/mingo/tip.git/README

and run perfstat on it (as root, to get the kernel-mode counts 
too):

   http://redhat.com/~mingo/perfcounters/perfstat.c

	Ingo

  reply	other threads:[~2009-02-24 17:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-24  6:05 Another Performance Regression in write() syscall Salman Qazi
2009-02-24  6:25 ` Dave Hansen
2009-02-24  8:47   ` Nick Piggin
2009-02-24 16:58     ` Dave Hansen
2009-02-24 17:29       ` Linus Torvalds
2009-02-24 17:50         ` Ingo Molnar [this message]
2009-02-25  3:49       ` Nick Piggin
2009-02-25  1:05   ` Salman Qazi

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=20090224175055.GA14534@elte.hu \
    --to=mingo@elte.hu \
    --cc=andi@firstfloor.org \
    --cc=dave@linux.vnet.ibm.com \
    --cc=haveblue@us.ibm.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --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 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.