[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090113084905.GA5837@nowhere>
Date: Tue, 13 Jan 2009 09:49:06 +0100
From: Frederic Weisbecker <fweisbec@...il.com>
To: Li Zefan <lizf@...fujitsu.com>
Cc: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Ingo Molnar <mingo@...e.hu>,
LKML <linux-kernel@...r.kernel.org>,
Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH] rcu: convert rcupreempt trace to seq file
On Tue, Jan 13, 2009 at 11:19:44AM +0800, Li Zefan wrote:
> > Indeed!
> >
> > The debugfs and seqfile handling and handled in the statistical
> > tracing engine.
> >
> > You just have to provide an iterator for your stat entries through two callbacks:
> >
> > _ stat_start() -> gives the first entry
> > _ stat_next() -> iterates over the next entry
> >
> > And an output callback
> >
> > _ stat_show() -> print one entry from your stat list
> >
> > And two optional things:
> >
> > _ stat_cmp() -> compare two entries, useful if you want your stats to be sorted
> > _ stat_headers() -> provide the first line in your stat file, typically to describe your columns
> >
> > The last thing you need is to give a name to your trace file.
> > You will retrieve it into /debugfs/tracing/trace_stat/your_file_name as a current snapshot
> > of your stats.
> >
> > It is currently used by the branch tracer, and by a pending patch for a new workqueue
> > tracer which will provide you a simple example.
> >
> > If you have any question about how to use it, don't hesitate to ask.
> >
>
> Hi Frederic,
>
> I've converted rcupreempt to use trace points, but I don't see much advantage to use
> trace stat instead of using seq_file directly.. And can you add support to allow
> me to provide stat_show() only ? I think it's common that the stat file has only
> one entry.
>
>
> Regards
> Li Zefan
It simplifies (I hope) a bit the seqfile.
The interface is very similar except that you don't need to deal
with debugfs stuffs, sorting, and position inside the seqfile.
And it unifies the stat files into a common directory instead of
having them grained into a mess of debugfs filesystem....
I could let it handle only stat_show when you have only one entry but that
would break the sense of stat_show.
If it's so common to have only one stat entry, perhaps I could provide a special callback
for that, something like stat_show_unique()...
Hm?
Frederic.
--
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