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:	Fri, 24 Jul 2009 09:05:18 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Zhaolei <zhaolei@...fujitsu.com>
cc:	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/3] Add walltime support for ring-buffer


On Fri, 24 Jul 2009, Zhaolei wrote:

> Hello, Steven
> 
> It is a prototype code to make ftrace display walltime of events.
> 
> It need to applys on my patch of:
> [PATCH v3 1/2] Add function to convert between calendar time and broken-down time for universal use
> 
> This code can run but need to be fixed, it only for demostrate what is result
> looks like.
> 
> I think display walltime is valuable for ftrace, it can provide more
> recognizable information to system manager that he can known "when"
> event happened.
> And it is also helpful for flight-recorder we are doing now, we can get
> walltime of events after panic for analyse.
> 
> We can get following result on this patch:
>  # cd /mnt/debugfs/tracing/
>  # echo sched_switch > current_tracer
>  # cat trace
>  # tracer: sched_switch
>  #
>  #           TASK-PID    CPU#    TIMESTAMP  FUNCTION
>  #              | |       |          |         |
>              bash-2457  [000]   214.895446:   2457:120:S   + [000]  2457:120:S bash
>              bash-2457  [000]   214.898298:   2457:120:R   + [000]     5:115:S events/0
>              bash-2457  [000]   214.898684:   2457:120:R ==> [000]     5:115:R events/0
>          events/0-5     [000]   214.899458:      5:115:R   + [000]  2455:120:S sshd
>          events/0-5     [000]   214.899495:      5:115:S ==> [000]  2455:120:R sshd
>  ...
>  # echo 1 > options/walltime
>  # cat trace
>  # tracer: sched_switch
>  #
>  #           TASK-PID    CPU#                  TIMESTAMP  FUNCTION
>  #              | |       |                        |         |
>            <idle>-0     [000] 2009-07-25 18:01:00.848468:      0:140:R ==> [000]     5:115:R events/0
>          events/0-5     [000] 2009-07-25 18:01:00.848523:      5:115:S ==> [000]     0:140:R <idle>
>            <idle>-0     [000] 2009-07-25 18:01:01.613479:      0:140:R   + [000]  2455:120:S sshd
>            <idle>-0     [000] 2009-07-25 18:01:01.613678:      0:140:R ==> [000]  2455:120:R sshd
>              sshd-2455  [000] 2009-07-25 18:01:01.614015:   2455:120:S   + [000]  2455:120:S sshd
>  ...
> 
> This patch is prototype because we have following things to do:
> 1: function to get walltime is not near rb_time_stamp()
>    So walltime is not absolutely synchronize with trace time.
>    But if we place code to get walltime near rb_time_stamp(), it will be called
>    on every reserve-event and will make system slow.
> 2: We can't call getnstimeofday() freely in ring-buffer's code, because
>    it is possibility already hold xtime_lock. Prototype code used a ugly way
>    to get gid of this problem, maybe we need to ftrace_disable_cpu() before
>    every write_seqlock() instead.
> 3: People maybe change walltime when tracing, but current ring-buffer page's
>    walltime can not reflect this change. We need to add tracepoints to watch
>    this change, and add a walltime-change event(already reserved in
>    ring-buffer.c) to record this change.
> 
> I'll continue to finish remain steps, what is your opinion on it?

Hi Zhaolei,

Could you not just save the wall time in some 64bit format within the 
current timestamp?  Right now there's three clocks that can be used by 
ftrace. Two that you can really get two (I need to add access to the 
third).  The default clock is sched_clock. But there's an option to get to 
global_clock:

 debug/tracing/options/global-clock

# echo 1 > /debug/tracing/options/global-clock

Will enable the global clock. Perhaps we can add a "wall clock" version 
that will map the timestamps to the wall clock?

I really hate adding any more fields to the ring buffer headers. That 
takes away from the amount that you can record per page.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ