linux-kernel - Re: [PATCH 4/5] tracing/fastboot: Add a time field on the sched

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]

Date:	Sun, 19 Oct 2008 00:34:16 +0200
From:	"Frédéric Weisbecker" <fweisbec@...il.com>
To:	"Tim Bird" <tim.bird@...sony.com>
Cc:	"Steven Rostedt" <rostedt@...dmis.org>,
	"Ingo Molnar" <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	"Arjan van de Ven" <arjan@...ux.intel.com>
Subject: Re: [PATCH 4/5] tracing/fastboot: Add a time field on the sched_switch entry

2008/10/18 Tim Bird <tim.bird@...sony.com>:
> I may have lost context here, but what's the purpose of the
> extra timestamp again?  If it's just to have zero-based
> timestamps on the ultimate output, can't you just put a single
> special "start" timestamp in the trace log.  Then that can
> be subtraced from all tracer-generated stamps in post-processing.
> I'm not familiar enough with the tracer to know if the
> post-processing is done in kernel space.  But in any event
> you could use something like scripts/show_delta to get
> relative timestamps (in user space).  Right now, scripts/show_delta
> doesn't act like a filter - I'll have to look at that.

Actually the problem is not really to have a zero-based timestamp but I need
to have a timestamp which is the same than the one used by the boot tracer.

If the boot tracer had only to capture one time per entry, I would use
the internal
timestamp of the ring-buffer. But the boot tracer must capture two
times: the call
time of an initcall and the time it returns.

At the same time I want to know the schedule events that occur during
the initcalls
and then the latency they raise. For that I need to have the same
timestamp than the boot
tracer to have a consistent view of these schedule events inside the initcalls.

But you just gave me a new idea :-)
If I split the initcall in two parts: the call and the return, I will
be able to drop these
boot-tracer-specific timestamps and just use the ring-buffer timestamp used
when an entry is appended into the buffer.
And so I can use the usual sched_switch events whithout additional field.

Seems to me really better.

But there is one thing that changes with this new way. It seems that
the ring buffer's timestamp
is based on the sched-clock and so I guess that's why it doesn't start
when the cpu boot but some
times after.

Arjan would you agree with this new time capture system?
--
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/