linux-kernel - Re: [PATCH 0/4] workqueue_tracepoint: Add worklet tracepoints for worklet lifecycle tracing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.00.0904242324260.24293@gandalf.stny.rr.com>
Date:	Fri, 24 Apr 2009 23:32:02 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	Frederic Weisbecker <fweisbec@...il.com>, zhaolei@...fujitsu.com,
	Ingo Molnar <mingo@...e.hu>, kosaki.motohiro@...fujitsu.com,
	tzanussi@...il.com, LKML <linux-kernel@...r.kernel.org>,
	oleg@...hat.com
Subject: Re: [PATCH 0/4] workqueue_tracepoint: Add worklet tracepoints for
 worklet lifecycle tracing


On Fri, 24 Apr 2009, Andrew Morton wrote:

> On Fri, 24 Apr 2009 22:51:03 -0400 (EDT) Steven Rostedt <rostedt@...dmis.org> wrote:
> 
> > In the old -rt patch series, we had trace points scattered all over the 
> > kernel. This was the original "event tracer". It was low overhead and can 
> > still give a good overview of the system when the function tracer was too 
> > much data. Yes, we solved many issues in -rt because of the event tracer. 
> 
> Sure, tracers can be useful.  The ext3 tracer I did way back when
> maintained a 32-element trace buffer inside each buffer_head and then would
> emit that trace when an assertion failed against that buffer_head, so
> you can see the last 32 things which happened to that bh.  It would
> have been nigh impossible to fix many of the things which were fixed
> without that facility.  (I doubt, incidentally, whether ftrace can do
> this sort of data-centric tracing?).

Not currently, but be careful what you say to me. I might implement it ;-)

Remember what happened when Ingo hypothetically asked me if it would be 
possible to trace all branches.

> 
> But I never merged it into Linux.  Some of the tracepoints are in there
> (grep TRACE fs/ext3/*.c) but the core was kept out-of-tree.

 grep TRACE fs/ext3/*.c |wc
     79     308    5010

Some?

This is exactly my point. We must still be frugal about what trace 
points gets into the kernel. But I think places that give a good idea of 
the events that are happening (stategically placed) can help the general 
community.

> 
> > BTW, you work for Google,
> 
> Hey, it's the other way round ;)

lol

> 
> > doesn't google claim to have some magical 
> > 20-some tracepoints that is all they need? Could you give us a hint to 
> > what and where they are?
> 
> Wouldn't have a clue.  Jiaying Zhang should be able to find out.
> 

OK, maybe I'll ping her next week.

Thanks,

-- Steve

--
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/