From: Ingo Molnar <mingo@elte.hu>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: "Pekka Enberg" <penberg@cs.helsinki.fi>,
"Andi Kleen" <andi@firstfloor.org>,
"Wu Fengguang" <fengguang.wu@intel.com>,
"Steven Rostedt" <rostedt@goodmis.org>,
"Fr馘駻ic Weisbecker" <fweisbec@gmail.com>,
"Larry Woodman" <lwoodman@redhat.com>,
"Peter Zijlstra" <a.p.zijlstra@chello.nl>,
"Eduard - Gabriel Munteanu" <eduard.munteanu@linux360.ro>,
"Andrew Morton" <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
"Matt Mackall" <mpm@selenic.com>,
"Alexey Dobriyan" <adobriyan@gmail.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [PATCH 5/5] proc: export more page flags in /proc/kpageflags
Date: Tue, 28 Apr 2009 14:42:59 +0200 [thread overview]
Message-ID: <20090428124259.GA3731@elte.hu> (raw)
In-Reply-To: <2f11576a0904280409h4dedc04u43a5b68ef492e56d@mail.gmail.com>
* KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
> 2009/4/28 Ingo Molnar <mingo@elte.hu>:
> >
> > * Pekka Enberg <penberg@cs.helsinki.fi> wrote:
> >
> >> Hi!
> >>
> >> 2009/4/28 KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>:
> >> >> I guess the main question here is whether this approach will scale to
> >> >> something like kmalloc() or the page allocator in production
> >> >> environments. For any serious workload, the frequency of events is
> >> >> going to be pretty high.
> >> >
> >> > Immediate Values patch series makes zero-overhead to tracepoint
> >> > while it's not used.
> >> >
> >> > So, We have to implement to stop collect stastics way. it restore
> >> > zero overhead world.
> >> > We don't lose any performance by trace.
> >>
> >> Sure but I meant the _enabled_ case here. kmalloc() (and the page
> >> allocator to some extent) is very performance sensitive in many
> >> workloads so you probably don't want to use tracepoints if you're
> >> collecting some overall statistics (i.e. tracing all events) like
> >> we do here.
> >
> > That's where 'collect current state' kind of tracepoints would help
> > - they could be used even without enabling any of the other
> > tracepoints. And they'd still be in a coherent whole with the
> > dynamic-events tracepoints.
> >
> > So i'm not arguing against these techniques at all - and we can move
> > on a wide scale from zero-overhead to lots-of-tracing-enabled models
> > - what i'm arguing against is the splintering.
>
> umm.
> I guess Pekka and you talk about different thing.
>
> if tracepoint is ON, tracepoint makes one function call. but few
> hot spot don't have patience to one function call overhead.
>
> scheduler stat and slab stat are one of good example, I think.
>
> I really don't want convert slab_stat and sched_stat to ftrace
> base stastics. currently it don't need extra function call and it
> only touch per-cpu variable. So, a overhead is extream small.
>
> Unfortunately, tracepoint still don't reach this extream
> performance.
I understand that - please see my "[rfc] object collection tracing"
reply in this thread, for a more detailed description about what i
meant under 'object state tracing'.
Ingo
--
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:[~2009-04-28 12:42 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-28 1:09 [PATCH 0/5] proc: export more page flags in /proc/kpageflags (take 4) Wu Fengguang
2009-04-28 1:09 ` [PATCH 1/5] pagemap: document clarifications Wu Fengguang
2009-04-28 7:11 ` Tommi Rantala
2009-04-28 1:09 ` [PATCH 2/5] pagemap: documentation 9 more exported page flags Wu Fengguang
2009-04-28 1:09 ` [PATCH 3/5] mm: introduce PageHuge() for testing huge/gigantic pages Wu Fengguang
2009-04-28 1:09 ` [PATCH 4/5] proc: kpagecount/kpageflags code cleanup Wu Fengguang
2009-04-28 1:09 ` [PATCH 5/5] proc: export more page flags in /proc/kpageflags Wu Fengguang
2009-04-28 6:55 ` Ingo Molnar
2009-04-28 7:40 ` Andi Kleen
2009-04-28 9:04 ` Pekka Enberg
2009-04-28 9:10 ` Andi Kleen
2009-04-28 9:15 ` Pekka Enberg
2009-04-28 9:15 ` Ingo Molnar
2009-04-28 9:19 ` Pekka Enberg
2009-04-28 9:25 ` Pekka Enberg
2009-04-28 9:36 ` Wu Fengguang
2009-04-28 9:36 ` Ingo Molnar
2009-04-28 9:57 ` Pekka Enberg
2009-04-28 10:10 ` KOSAKI Motohiro
2009-04-28 10:21 ` Pekka Enberg
2009-04-28 10:56 ` Ingo Molnar
2009-04-28 11:09 ` KOSAKI Motohiro
2009-04-28 12:42 ` Ingo Molnar [this message]
2009-04-28 11:03 ` Ingo Molnar
2009-04-28 17:42 ` Matt Mackall
2009-04-28 9:29 ` Ingo Molnar
2009-04-28 9:34 ` KOSAKI Motohiro
2009-04-28 9:38 ` Ingo Molnar
2009-04-28 9:55 ` Wu Fengguang
2009-04-28 10:11 ` KOSAKI Motohiro
2009-04-28 11:05 ` Ingo Molnar
2009-04-28 11:36 ` Wu Fengguang
2009-04-28 12:17 ` [rfc] object collection tracing (was: [PATCH 5/5] proc: export more page flags in /proc/kpageflags) Ingo Molnar
2009-04-28 13:31 ` Wu Fengguang
2009-05-12 13:01 ` Frederic Weisbecker
2009-05-17 13:36 ` Wu Fengguang
2009-05-17 13:55 ` Frederic Weisbecker
2009-05-17 14:12 ` Wu Fengguang
2009-05-18 11:44 ` KOSAKI Motohiro
2009-05-18 11:47 ` Wu Fengguang
2009-04-28 10:18 ` [PATCH 5/5] proc: export more page flags in /proc/kpageflags Andi Kleen
2009-04-28 8:33 ` Wu Fengguang
2009-04-28 9:24 ` Ingo Molnar
2009-04-28 18:11 ` Tony Luck
2009-04-28 18:34 ` Matt Mackall
2009-04-28 20:47 ` Tony Luck
2009-04-28 20:54 ` Andi Kleen
2009-04-28 20:59 ` Matt Mackall
2009-04-28 21:17 ` Andrew Morton
2009-04-28 21:49 ` Matt Mackall
2009-04-29 0:02 ` Robin Holt
2009-04-28 17:49 ` Matt Mackall
2009-04-29 8:05 ` Wu Fengguang
2009-04-29 19:13 ` Matt Mackall
2009-04-30 1:00 ` Wu Fengguang
2009-04-28 21:32 ` Andrew Morton
2009-04-28 22:46 ` Matt Mackall
2009-04-28 23:02 ` Andrew Morton
2009-04-28 23:31 ` Matt Mackall
2009-04-28 23:42 ` Andrew Morton
2009-04-28 23:55 ` Matt Mackall
2009-04-29 3:33 ` Wu Fengguang
2009-04-29 2:38 ` Wu Fengguang
2009-04-29 2:55 ` Andrew Morton
2009-04-29 3:48 ` Wu Fengguang
2009-04-29 5:09 ` Wu Fengguang
2009-04-29 4:41 ` Nathan Lynch
2009-04-29 4:50 ` Andrew Morton
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=20090428124259.GA3731@elte.hu \
--to=mingo@elte.hu \
--cc=a.p.zijlstra@chello.nl \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=eduard.munteanu@linux360.ro \
--cc=fengguang.wu@intel.com \
--cc=fweisbec@gmail.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lwoodman@redhat.com \
--cc=mpm@selenic.com \
--cc=penberg@cs.helsinki.fi \
--cc=rostedt@goodmis.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;
as well as URLs for NNTP newsgroup(s).