linux-kernel - Re: [RFC PATCH 16/22 -v2] add get_monotonic

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:	Thu, 17 Jan 2008 16:03:50 -0500 (EST)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	"Frank Ch. Eigler" <fche@...hat.com>
cc:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Christoph Hellwig <hch@...radead.org>,
	Gregory Haskins <ghaskins@...ell.com>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	Tim Bird <tim.bird@...sony.com>,
	Sam Ravnborg <sam@...nborg.org>,
	Steven Rostedt <srostedt@...hat.com>,
	Paul Mackerras <paulus@...ba.org>,
	Daniel Walker <dwalker@...sta.com>
Subject: Re: [RFC PATCH 16/22 -v2] add get_monotonic_cycles


On Thu, 17 Jan 2008, Frank Ch. Eigler wrote:

> Hi -
>
> On Thu, Jan 17, 2008 at 03:08:33PM -0500, Steven Rostedt wrote:
> > [...]
> > +       trace_mark(kernel_sched_schedule,
> > +               "prev_pid %d next_pid %d prev_state %ld",
> > +               prev->pid, next->pid, prev->state);
> > [...]
> > But...
> >
> > Tracers that want to do a bit more work, like recording timings and seeing
> > if we hit some max somewhere, can't do much with that pretty print data.
>
> If you find yourself wanting to perform computations like finding
> maxima, or responding right there as opposed to later during userspace
> trace data extraction, then you're trending toward a tool like
> systemtap.

Yes, very much so. I'm working on getting the latency_tracer from the -rt
patch into something suitable for mainline. We need to calculate the max
latencies on the fly. If we hit a max, then we save it off, otherwise, we
blow away the trace and start again.

>
> > [...]
> > So, at a minimum, I'd like to at least have meta data attached:
> > 	trace_mark(kernel_sched_schedule,
> > 		"prev_pid %d next_pid %d prev_state %ld\0"
> > 		"prev %p next %p",
> > 		prev->pid, next->pid, prev->state,
> > 		prev, next);
> >
> > This would allow for both the nice pretty print of your trace, as well as
> > allowing other tracers to get to better meta data.
>
> Yes, more self-contained marker events are necessary for meaningful
> in-situ processing.  That needs to be balanced by the increased cost
> for computing and passing the extra parameters, multiplied the event
> occurrence rate.

The cost is only done when the marker is armed. Since the marker is an
unlikely, and will be placed at the end of the function.

>
> In this case, the prev/next pointers are sufficient to compute the
> other values.  For particularly performance-critical markers, it may
> not be unreasonable to expect the callback functions to dereference
> such pointers for pretty-printing or other processing.

This was exactly my point to Mathieu, but I think he has LTTng very much
coupled with the markers. I haven't played with LTTng (yet), but from what
I've read (Mathieu, correct me if I'm wrong), it seems that all the
markers become visible to userspace, and the user can simple turn them on
or off. LTTng doesn't need any knowledge of the marker since the marker
contains how to print the information.

So* by placing a "prev %p next %p" as the only information, we lose out on
this automated way LTTng works. Because the two pointers are just
meaningless numbers to the user.

>
> > The '\0' would keep your tracer from recording the extra data, and we
> > could add some way to ignore the parameters in the printf to let other
> > traces get straight to the meta data.
>
> This \0 hack is perhaps too clever.  Much of the cost of the extra
> parameters is already paid by the time that a simpleminded tracing
> callback function starts going through the string.  Also, I believe
> the systemtap marker interface would break if the format strings were
> not singly terminated ordinary strings.

Well, actually when I first wrote this letter, I used "--" as a delimiter
to allow a tool to hide the pretty stuff. But then I thought about the
"clever hack" with the '\0',  The "--" may be better since it wont break
systemtap.

-- Steve

* dvhart - bah!

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