All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	prasad@linux.vnet.ibm.com,
	Mathieu Desnoyers <compudj@krystal.dyndns.org>,
	"Frank Ch. Eigler" <fche@redhat.com>,
	David Wilder <dwilder@us.ibm.com>,
	hch@lst.de, Martin Bligh <mbligh@google.com>,
	Christoph Hellwig <hch@infradead.org>,
	Steven Rostedt <srostedt@redhat.com>
Subject: Re: [RFC PATCH 1/2 v2] Unified trace buffer
Date: Thu, 25 Sep 2008 10:02:02 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.1.10.0809250952460.3265@nehalem.linux-foundation.org> (raw)
In-Reply-To: <20080925160048.641420646@goodmis.org>



On Thu, 25 Sep 2008, Steven Rostedt wrote:
> +
> +/**
> + * ring_buffer_event_length - return the length of the event
> + * @event: the event to get the length of
> + *
> + * Note, if the event is bigger than 256 bytes, the length
> + * can not be held in the shifted 5 bits. The length is then
> + * added as a short (unshifted) in the body.

The comment seems stale ;)

> +
> +/**
> + * ring_buffer_peek - peek at the next event to be read
> + * @iter: The ring buffer iterator
> + * @iter_next_cpu: The CPU that the next event belongs on
> + *
> + * This will return the event that will be read next, but does
> + * not increment the iterator.
> + */
> +struct ring_buffer_event *
> +ring_buffer_peek(struct ring_buffer *buffer, int cpu, u64 *ts)
> +{
> +	struct ring_buffer_per_cpu *cpu_buffer;
> +	struct ring_buffer_event *event;
> +	u64 delta;
> +
> +	cpu_buffer = buffer->buffers[cpu];
> +
> + again:
> +	if (ring_buffer_per_cpu_empty(cpu_buffer))
> +		return NULL;
> +
> +	event = ring_buffer_head_event(cpu_buffer);
> +
> +	switch (event->type) {
> +	case RB_TYPE_PADDING:
> +		ring_buffer_inc_page(buffer, &cpu_buffer->head_page);
> +		rb_reset_read_page(cpu_buffer);
> +		goto again;
> +
> +	case RB_TYPE_TIME_EXTENT:
> +		delta = event->data;
> +		delta <<= TS_SHIFT;
> +		delta += event->time_delta;
> +		cpu_buffer->read_stamp += delta;
> +		goto again;
> +
> +	case RB_TYPE_TIME_STAMP:
> +		/* FIXME: not implemented */
> +		goto again;
> +
> +	case RB_TYPE_SMALL_DATA:
> +	case RB_TYPE_LARGE_DATA:
> +	case RB_TYPE_STRING:
> +		if (ts)
> +			*ts = cpu_buffer->read_stamp + event->time_delta;
> +		return event;

Your timestamp handling seems odd. You do it per-event, but I think it 
should happen for all events, ie just do

	*ts += event->time_delta;

_outside_ the case statement, and then in RB_TYPE_TIME_EXTENT you'd do 
either

 - relative:
	*ts += event->data << TS_SHIFT;

 - absolute timestamp events:
	*ts = (event->data << TS_SHIFT) + event->time_delta;

but the bigger issue is that I think the timestamp should be relative to 
the _previous_ event, not relative to the page start. IOW, you really 
should accumulate them. 

IOW, the base timestamp cannot be in the cpu_buffer, it needs to be in the 
iterator data structure, since it updates as you walk over it.

Otherwise the extended TSC format will be _horrible_. You don't want to 
add it in front of every event in the page just because you had a pause at 
the beginning of the page. You want to have a running update, so that you 
only need to add it after there was a pause.

		Linus

  reply	other threads:[~2008-09-25 17:04 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-25 15:58 [RFC PATCH 0/2 v2] Unified trace buffer (take two) Steven Rostedt
2008-09-25 15:58 ` [RFC PATCH 1/2 v2] Unified trace buffer Steven Rostedt
2008-09-25 17:02   ` Linus Torvalds [this message]
2008-09-25 17:16     ` Steven Rostedt
2008-09-25 17:25       ` Linus Torvalds
2008-09-25 17:46         ` Steven Rostedt
2008-09-25 17:35     ` Mathieu Desnoyers
2008-09-25 17:48       ` Steven Rostedt
2008-09-25 18:25         ` Mathieu Desnoyers
2008-09-25 15:58 ` [RFC PATCH 2/2 v2] ftrace: make work with new ring buffer Steven Rostedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.1.10.0809250952460.3265@nehalem.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=compudj@krystal.dyndns.org \
    --cc=dwilder@us.ibm.com \
    --cc=fche@redhat.com \
    --cc=hch@infradead.org \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@google.com \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=prasad@linux.vnet.ibm.com \
    --cc=rostedt@goodmis.org \
    --cc=srostedt@redhat.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.