From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: akpm@linux-foundation.org, Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Masami Hiramatsu <mhiramat@redhat.com>,
linux-mm@kvack.org, Dave Hansen <haveblue@us.ibm.com>,
"Frank Ch. Eigler" <fche@redhat.com>,
Hideo AOKI <haoki@redhat.com>,
Takashi Nishiie <t-nishiie@np.css.fujitsu.com>,
Steven Rostedt <rostedt@goodmis.org>,
Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
Subject: Re: [patch 09/17] LTTng instrumentation - filemap
Date: Thu, 17 Jul 2008 03:02:07 -0400 [thread overview]
Message-ID: <20080717070207.GA30312@Krystal> (raw)
In-Reply-To: <200807171625.25302.nickpiggin@yahoo.com.au>
* Nick Piggin (nickpiggin@yahoo.com.au) wrote:
> On Wednesday 16 July 2008 08:26, Mathieu Desnoyers wrote:
> > Instrumentation of waits caused by memory accesses on mmap regions.
> >
> > Those tracepoints are used by LTTng.
> >
> > About the performance impact of tracepoints (which is comparable to
> > markers), even without immediate values optimizations, tests done by Hideo
> > Aoki on ia64 show no regression. His test case was using hackbench on a
> > kernel where scheduler instrumentation (about 5 events in code scheduler
> > code) was added. See the "Tracepoints" patch header for performance result
> > detail.
>
> BTW. this sort of test is practically useless to measure overhead. If
> a modern CPU is executing out of primed insn/data and branch prediction
> cache, then yes this sort of thing is pretty well free.
>
> I see *real* workloads that have got continually and incrementally slower
> eg from 2.6.5 to 2.6.20+ as "features" get added. Surprisingly, none of
> them ever showed up individually on a microbenchmark.
>
> OK, for this case if you can configure it out, I guess that's fine. But
> let's not pretend that adding code and branches and function calls are
> ever free.
I never pretended anything like that. Actually, that's what the
"immediate values" are for : they allow to patch load immediate value
instead of a memory read to decrease d-cache impact. They now allow to
patch a jump instead of the memory read/immediate value read + test +
conditional branch to skip the function call with fairly minimal impact.
I agree with you that eating precious d-cache and jump prediction buffer
entries can eventually slow down the system. But this will be _hard_ to
show on a single macro benchmark, and the microbenchmark showing it will
have to be taken in conditions which will exacerbate the d-cache and BPB
impact.
Mathieu
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
WARNING: multiple messages have this Message-ID (diff)
From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: akpm@linux-foundation.org, Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Masami Hiramatsu <mhiramat@redhat.com>,
linux-mm@kvack.org, Dave Hansen <haveblue@us.ibm.com>,
"Frank Ch. Eigler" <fche@redhat.com>,
Hideo AOKI <haoki@redhat.com>,
Takashi Nishiie <t-nishiie@np.css.fujitsu.com>,
Steven Rostedt <rostedt@goodmis.org>,
Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
Subject: Re: [patch 09/17] LTTng instrumentation - filemap
Date: Thu, 17 Jul 2008 03:02:07 -0400 [thread overview]
Message-ID: <20080717070207.GA30312@Krystal> (raw)
In-Reply-To: <200807171625.25302.nickpiggin@yahoo.com.au>
* Nick Piggin (nickpiggin@yahoo.com.au) wrote:
> On Wednesday 16 July 2008 08:26, Mathieu Desnoyers wrote:
> > Instrumentation of waits caused by memory accesses on mmap regions.
> >
> > Those tracepoints are used by LTTng.
> >
> > About the performance impact of tracepoints (which is comparable to
> > markers), even without immediate values optimizations, tests done by Hideo
> > Aoki on ia64 show no regression. His test case was using hackbench on a
> > kernel where scheduler instrumentation (about 5 events in code scheduler
> > code) was added. See the "Tracepoints" patch header for performance result
> > detail.
>
> BTW. this sort of test is practically useless to measure overhead. If
> a modern CPU is executing out of primed insn/data and branch prediction
> cache, then yes this sort of thing is pretty well free.
>
> I see *real* workloads that have got continually and incrementally slower
> eg from 2.6.5 to 2.6.20+ as "features" get added. Surprisingly, none of
> them ever showed up individually on a microbenchmark.
>
> OK, for this case if you can configure it out, I guess that's fine. But
> let's not pretend that adding code and branches and function calls are
> ever free.
I never pretended anything like that. Actually, that's what the
"immediate values" are for : they allow to patch load immediate value
instead of a memory read to decrease d-cache impact. They now allow to
patch a jump instead of the memory read/immediate value read + test +
conditional branch to skip the function call with fairly minimal impact.
I agree with you that eating precious d-cache and jump prediction buffer
entries can eventually slow down the system. But this will be _hard_ to
show on a single macro benchmark, and the microbenchmark showing it will
have to be taken in conditions which will exacerbate the d-cache and BPB
impact.
Mathieu
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2008-07-17 7:02 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-15 22:26 [patch 00/17] Tracepoints v4 for linux-next Mathieu Desnoyers
2008-07-15 22:26 ` [patch 01/17] RCU read sched Mathieu Desnoyers
2008-08-01 21:10 ` Paul E. McKenney
2008-08-01 23:04 ` Peter Zijlstra
2008-07-15 22:26 ` [patch 02/17] Kernel Tracepoints Mathieu Desnoyers
2008-07-24 15:08 ` Steven Rostedt
2008-07-24 20:18 ` Mathieu Desnoyers
2008-08-01 21:10 ` Paul E. McKenney
2008-08-04 15:17 ` Mathieu Desnoyers
2008-07-24 15:34 ` Steven Rostedt
2008-07-24 20:30 ` Mathieu Desnoyers
2008-07-24 22:22 ` Steven Rostedt
2008-07-24 15:39 ` Steven Rostedt
2008-07-24 20:37 ` [PATCH] Tracepoints use TABLE_SIZE macro Mathieu Desnoyers
2008-07-15 22:26 ` [patch 03/17] Tracepoints Documentation Mathieu Desnoyers
2008-07-15 22:26 ` [patch 04/17] Tracepoints Samples Mathieu Desnoyers
2008-07-15 22:26 ` [patch 05/17] LTTng instrumentation - irq Mathieu Desnoyers
2008-07-15 22:26 ` [patch 06/17] LTTng instrumentation - scheduler Mathieu Desnoyers
2008-07-16 8:30 ` Peter Zijlstra
2008-07-16 14:18 ` Mathieu Desnoyers
2008-07-15 22:26 ` [patch 07/17] LTTng instrumentation - timer Mathieu Desnoyers
2008-07-16 8:34 ` Peter Zijlstra
2008-07-16 14:34 ` Mathieu Desnoyers
2008-07-15 22:26 ` [patch 08/17] LTTng instrumentation - kernel Mathieu Desnoyers
2008-07-24 13:57 ` Steven Rostedt
2008-07-24 14:30 ` Mathieu Desnoyers
2008-07-24 15:13 ` Steven Rostedt
2008-07-15 22:26 ` [patch 09/17] LTTng instrumentation - filemap Mathieu Desnoyers
2008-07-15 22:26 ` Mathieu Desnoyers
2008-07-16 8:35 ` Peter Zijlstra
2008-07-16 8:35 ` Peter Zijlstra
2008-07-16 14:37 ` Mathieu Desnoyers
2008-07-16 14:37 ` Mathieu Desnoyers
2008-07-17 6:25 ` Nick Piggin
2008-07-17 6:25 ` Nick Piggin
2008-07-17 7:02 ` Mathieu Desnoyers [this message]
2008-07-17 7:02 ` Mathieu Desnoyers
2008-07-17 7:11 ` Nick Piggin
2008-07-17 7:11 ` Nick Piggin
2008-07-15 22:26 ` [patch 10/17] LTTng instrumentation - swap Mathieu Desnoyers
2008-07-15 22:26 ` Mathieu Desnoyers
2008-07-16 8:39 ` Peter Zijlstra
2008-07-16 8:39 ` Peter Zijlstra
2008-07-16 14:40 ` Mathieu Desnoyers
2008-07-16 14:40 ` Mathieu Desnoyers
2008-07-16 14:47 ` Peter Zijlstra
2008-07-16 14:47 ` Peter Zijlstra
2008-07-16 15:00 ` Mathieu Desnoyers
2008-07-16 15:00 ` Mathieu Desnoyers
2008-07-16 15:50 ` KOSAKI Motohiro
2008-07-16 15:50 ` KOSAKI Motohiro
2008-07-16 16:17 ` Mathieu Desnoyers
2008-07-16 16:17 ` Mathieu Desnoyers
2008-07-15 22:26 ` [patch 11/17] LTTng instrumentation - memory page faults Mathieu Desnoyers
2008-07-15 22:26 ` Mathieu Desnoyers
2008-07-15 22:26 ` [patch 12/17] LTTng instrumentation - page Mathieu Desnoyers
2008-07-16 8:41 ` Peter Zijlstra
2008-07-16 15:03 ` Mathieu Desnoyers
2008-07-15 22:26 ` [patch 13/17] LTTng instrumentation - hugetlb Mathieu Desnoyers
2008-07-15 22:26 ` [patch 14/17] LTTng instrumentation - net Mathieu Desnoyers
2008-07-15 22:26 ` [patch 15/17] LTTng instrumentation - ipv4 Mathieu Desnoyers
2008-07-15 22:26 ` [patch 16/17] LTTng instrumentation - ipv6 Mathieu Desnoyers
2008-07-15 22:26 ` [patch 17/17] ftrace port to tracepoints Mathieu Desnoyers
2008-07-16 8:51 ` [patch 00/17] Tracepoints v4 for linux-next Peter Zijlstra
2008-07-18 15:41 ` Masami Hiramatsu
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=20080717070207.GA30312@Krystal \
--to=mathieu.desnoyers@polymtl.ca \
--cc=akpm@linux-foundation.org \
--cc=eduard.munteanu@linux360.ro \
--cc=fche@redhat.com \
--cc=haoki@redhat.com \
--cc=haveblue@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhiramat@redhat.com \
--cc=mingo@elte.hu \
--cc=nickpiggin@yahoo.com.au \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=t-nishiie@np.css.fujitsu.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 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.