[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1240940528.938.426.camel@calx>
Date: Tue, 28 Apr 2009 12:42:08 -0500
From: Matt Mackall <mpm@...enic.com>
To: Ingo Molnar <mingo@...e.hu>
Cc: Pekka Enberg <penberg@...helsinki.fi>,
Andi Kleen <andi@...stfloor.org>,
Wu Fengguang <fengguang.wu@...el.com>,
Steven Rostedt <rostedt@...dmis.org>,
Frédéric 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>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.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
On Tue, 2009-04-28 at 11:36 +0200, Ingo Molnar wrote:
> I 'integrate' traces all the time to get summary counts. This series
> of dynamic events:
>
> allocation
> page count up
> page count up
> page count down
> page count up
> page count up
> page count up
> page count up
>
> integrates into: "page count is 6".
Perhaps you've failed calculus. The integral is 6 + C.
This is a critical distinction. Tracing is great for looking at changes,
but it completely falls down for static system-wide measurements because
it would require integrating from time=0 to get a meaningful summation.
That's completely useless for taking a measurement on a system that
already has an uptime of months.
Never mind that summing up page flag changes for every page on the
system since boot time through the trace interface is incredibly
wasteful given that we're keeping a per-page integral in the page tables
anyway.
Tracing is not the answer for everything.
--
http://selenic.com : development and support for Mercurial and Linux
--
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