linux-kernel - Re: [PATCH 2/2] tracing/function-graph-tracer: use the more lightweight local clock

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]

Date:	Thu, 5 Mar 2009 09:46:40 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Steven Rostedt <rostedt@...dmis.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] tracing/function-graph-tracer: use the more
	lightweight local clock

On Thu, Mar 05, 2009 at 08:30:13AM +0100, Peter Zijlstra wrote:
> On Thu, 2009-03-05 at 02:19 +0100, Frederic Weisbecker wrote:
> 
> > It takes 1 ms to execute while tracing.
> > Considering my frequency is 250 Hz, it means 1/4 of the system is used
> > on timer interrupt while tracing.
> > 
> > For now the hang is fixed, but not the awful latency. And I'm just too frightened
> > to test it on 1000 Hz.
> > 
> > But I plan to add a kind of watchdog to check how many time we spent inside an
> > interrupt while graph tracing.
> > By checking this time against the current Hz value, I could decide to abort the tracing
> > for all irq.
> 
> That would basically render the thing useless :-(


It would be only for slow machines :-)
I'm talking about something that happened on a Pentium II.

 
> Is it specifically function_graph that is so expensive? If so, is that
> because of the function exit hook?


Yes, specifically the function_graph, the function tracer is not concerned.
The function graph tracer takes more than double overhead compared to the function
tracer.

Usually the function tracer hooks directly the the function that insert the event, it's
pretty straightforward.

The function graph does much more work: 

entry: basic checks, take the time, push the infos on the stack, insert an event
       on the ring-buffer, hook the return value.
return: pop the infos from stack, insert an event on the ring-buffer, jump
        to the original caller.

It has a high cost... which makes me sad because I plan to port it in on Arm and I fear
the little Arm boad I recently purshased will not let me trace the interrupts without hanging...
:-(

I guess I should start thinking on some optimizations, perhaps using perfcounter?

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