[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <496C58C9.5080807@cn.fujitsu.com>
Date: Tue, 13 Jan 2009 17:03:05 +0800
From: Li Zefan <lizf@...fujitsu.com>
To: Frederic Weisbecker <fweisbec@...il.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
Frederic Weisbecker wrote:
> 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....
>
OK. It makes things easier for some cases. :)
But will trace_stat/ become a mess when there are many stat files in it ?
Does it make sense to support making subdir in trace_stat/ ?
> 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?
>
stat_show_single() ? I don't know which name is better.
Like it's common to use single_open with seq_file, I think it's needed as we add more
stat files into trace_stat.
Regards
Li Zefan
--
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