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] [day] [month] [year] [list]
Message-ID: <878uzlurv5.fsf@sejong.aot.lge.com>
Date:	Thu, 29 Aug 2013 11:56:46 +0900
From:	Namhyung Kim <namhyung@...nel.org>
To:	Jeremy Eder <jeder@...hat.com>
Cc:	Jiri Olsa <jolsa@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Mackerras <paulus@...ba.org>,
	Ingo Molnar <mingo@...nel.org>,
	Namhyung Kim <namhyung.kim@....com>,
	LKML <linux-kernel@...r.kernel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	David Ahern <dsahern@...il.com>,
	Stephane Eranian <eranian@...gle.com>
Subject: Re: [PATCHSET 00/17] perf tools: Introduce new 'ftrace' command (v4)

Hi Jeremy,

On Wed, 28 Aug 2013 10:57:08 -0400, Jeremy Eder wrote:
> On 130813 11:20:52, Namhyung Kim wrote:
>> @@ -579,6 +587,8 @@ out:
>>  		pthread_cond_signal(&recorder_ready_cond);
>>  		pthread_mutex_unlock(&recorder_mutex);
>>  	}
>> +
>> +	pr_debug2("done with %ld bytes\n", (long)byte_written);
>>  	return fra;
>>  }
>>  
>
> Hmm, I already had hunk #3 in your git tree v4.

Oops, sorry about that.

>
>> @@ -1139,12 +1149,12 @@ retry:
>>  		return record;
>>  	}
>>  
>> -	munmap(fra->map, pevent_get_page_size(ftrace->pevent));
>> -	fra->map = NULL;
>> -
>>  	if (fra->done)
>>  		return NULL;
>>  
>> +	munmap(fra->map, pevent_get_page_size(ftrace->pevent));
>> +	fra->map = NULL;
>> +
>>  	fra->offset += pevent_get_page_size(ftrace->pevent);
>>  	if (fra->offset >= fra->size) {
>>  		/* EOF */
>
>
> After patching your tree with just the first 2 hunks, I'm able to
> get ftrace-style function graphing out of perf.
>
> # ./perf ftrace record df
> Filesystem           1K-blocks     Used Available Use% Mounted on
> <snip>...
>
> # ./perf --no-pager ftrace show | head -20
> overriding event (11) ftrace:funcgraph_entry with new print handler
> overriding event (10) ftrace:funcgraph_exit with new print handler
>   2)   0.686 us |  finish_task_switch();
>   2)   0.260 us |  finish_wait();
>   2)            |  mutex_lock() {
>   2)   0.211 us |    _cond_resched();
>   2)   1.170 us |  }
>   2)   0.319 us |  generic_pipe_buf_confirm();
>   2)   0.261 us |  generic_pipe_buf_map();
>   2)   0.129 us |  generic_pipe_buf_unmap();
>   2)   0.747 us |  anon_pipe_buf_release();
>   2)   0.138 us |  mutex_unlock();
>   2)            |  __wake_up_sync_key() {
>   2)   0.279 us |    _raw_spin_lock_irqsave();
>   2)   0.135 us |    __wake_up_common();
>   2)   0.133 us |    __lock_text_start();
>   2)   3.386 us |  }
>   2)            |  kill_fasync() {
>   2)            |  smp_reschedule_interrupt() {
>   2)   0.130 us |    kvm_guest_apic_eoi_write();
>
> Nice.

Glad to see this. :)

>
> Not sure if you intend to move all ftrace functionality over to
> perf ftrace, but the function graph timings is a great start and something sorely
> missing.
>
> Do you intend to add -e event support or -l function-specific options ?  In the real
> world, without filtering on events or functions, I've had systems hang, plus
> performance impact is too great.
>
> A common invocation of ftrace via trace-cmd is:
> # trace-cmd record -p function_graph -e irq:* -l do_IRQ ping -c1 www.redhat.com
>
> So possible perf equivalent?
> # ./perf ftrace record -e irq:* -e do_IRQ ping -c1 www.redhat.com

Yes I'm considering adding more features in trace-cmd to perf ftrace.
The function filtering is the one in the highest priority.  I also want
to add support for other events but it needs bit more thinking.

Thanks,
Namhyung
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ