[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <84144f020904280321u4be9fb10t6f0123b589752b80@mail.gmail.com>
Date: Tue, 28 Apr 2009 13:21:50 +0300
From: Pekka Enberg <penberg@...helsinki.fi>
To: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Cc: Ingo Molnar <mingo@...e.hu>, Andi Kleen <andi@...stfloor.org>,
Wu Fengguang <fengguang.wu@...el.com>,
Steven Rostedt <rostedt@...dmis.org>,
Fr馘駻ic Weisbecker
<fweisbec@...il.com>, Larry Woodman <lwoodman@...hat.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Eduard - Gabriel Munteanu <eduard.munteanu@...ux360.ro>,
Andrew Morton <akpm@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
Matt Mackall <mpm@...enic.com>,
Alexey Dobriyan <adobriyan@...il.com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [PATCH 5/5] proc: export more page flags in /proc/kpageflags
Hi!
2009/4/28 KOSAKI Motohiro <kosaki.motohiro@...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.
Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists