linux-kernel - Re: [PATCH 1/3] ftrace: add tracepoint for timer

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: <alpine.LFD.2.00.0906101225280.3351@localhost.localdomain>
Date:	Wed, 10 Jun 2009 12:58:38 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Xiao Guangrong <xiaoguangrong@...fujitsu.com>
cc:	Zhaolei <zhaolei@...fujitsu.com>, mingo@...e.hu,
	LKML <linux-kernel@...r.kernel.org>,
	kosaki.motohiro@...fujitsu.com,
	Steven Rostedt <rostedt@...dmis.org>, fweisbec@...il.com
Subject: Re: [PATCH 1/3] ftrace: add tracepoint for timer

Xiao,

On Wed, 10 Jun 2009, Xiao Guangrong wrote:
> Those tracepoints are wanted and useful:
> 1) We can detect a timer's delay if jiffies info is added, like this:
> 
> 	XXX: timer_start: timer=e0b374e0 func=test_timerfuc expires=4294941565
> 	XXX: timer_expire: timer=e0b374e0 func=test_timerfuc jiffies=4294941567
>    We expect the timer expires at 4294941565, actually the timer expires at
>    4294941567, so it is delayed by 2 jiffies.

You can achive the same thing by storing (expires - jiffies) when you
trace the timer start. Then you can calc the delta from the trace
timestamps, but I have no strong opinion about that.

> 2) We can monitor the lifecycle and behaviors of a timer, for
>    example, when monitoring dirty writeback timer, I found reading
>    /proc/sys/vm/dirty_writeback_centisecs will reset the timer:

 
> 3) We are developing "flight-record" using crash. It can read out the ring
>    buffer from the dump file, and let us know what was happening before
>    kernel panic, so we may find the cause of the panic. This requires
>    well-defined tracepoints in different kernel subsystems, especially some
>    core subsystems, timer is surely one of them.

I'm not arguing that tracepoints are not useful, but you can achieve
all the things above by combining them in an unintrusive way to the
existing debug points.

This results in the minimum noise of debug/trace insertions into the
code, which keeps it readable and maintainable. That's all I want.

Thanks,

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