Re: [RFC PATCH 1/4] kmemtrace: Core implementation.

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Pekka Enberg <penberg@...>
Cc: Eduard - Gabriel Munteanu <eduard.munteanu@...>, <cl@...>, <linux-mm@...>, <linux-kernel@...>, <rdunlap@...>, <mpm@...>, Steven Rostedt <rostedt@...>, Thomas Gleixner <tglx@...>
Date: Monday, July 28, 2008 - 12:29 pm

* Pekka Enberg (penberg@cs.helsinki.fi) wrote:

Documentation should probably come in a separate patch.


Hmm ? why record an invalid event ?? I see it's not used in the code, is
that actually used in some way because the memory is set to 0 ?



If only valid for event ID 1 and only in NUMA case, please don't waste
space in each event header and make that a event-specific field... ?


Not true on 32 bits machines. You are wasting 4 bytes on those archs.


Same here.


Same here.


And here.


8 bytes for GFP flags ?? Whoah, that's a lot of one-hot bits ! :) I knew
that some allocators were bloated, bit not that much. :)


With a heartbeat, as lttng does, you can cut that to a 4 bytes field.


Using a magic number in the trace header lets you deal with
cross-endianness.

Saving the type sizes in the trace header lets you deal with different
int/long/pointer type sizes.


I personally prefer a self-describing trace :)


That kind of stuff would be nice to have in lttng.


Not currently true : cross-endianness/wastes space for 32 bits archs.


LTTng will be faster though : per-cpu atomic ops instead of interrupt
disable makes the probe faster.


Automatic description of markers and dynamic assignation of IDs to
markers should provide a bit more flexibility here.



Change the documentation to prefix a root command line by "#" instead of
leaving this weird comment.


What in the world can be causing that ? Shouldn't it be fixed ? It might
be due to unexpected allocator behavior, non-instrumented alloc/free
code or broken tracer....



See below for detail, but this event record is way too big and not
adapted to 32 bits architectures.


This could be trivially turned into a tracepoint probe.


Isn't this overridable by a command line param ? Shouldn't it be called
"DEFAULT_KMEMTRACE_*" then ?


Hrm, I'd leave that as a kernel command line option, not config option.
If you ever want to _aways_ have it on, then change your lilo/grub file.


Argh, and you do a supplementary copy here. You could simply alias the
buffers and write directly to them after reserving the correct amount of
space.


ktime_get is monotonic, but with potentially coarse granularity. I see
that you use ktime_to_ns here, which gives you a resolution of 1 timer
tick in the case where the TSCs are not synchronized. While it should be
"good enough" for the scheduler, I doubt it's enough for a tracer.

It also takes the xtime seqlock, which adds a potentially big delay to
the tracing code (if you read the clock while the writer lock is taken).

Also, when NTP modifies the clock, although it stays monotonic, the rate
at which it increments can dramatically change. I doubt you want to use
that as a reference for performance analysis.



I think the standard is to use =0, =1 here, not =yes, =no ?

Mathieu


-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[RFC PATCH 0/4] kmemtrace RFC (resend 2, fixed wrong Cc), Eduard - Gabriel Munteanu..., (Tue Jul 22, 2:36 pm)
[RFC PATCH 1/4] kmemtrace: Core implementation., Eduard - Gabriel Munteanu..., (Tue Jul 22, 2:36 pm)
Re: [RFC PATCH 1/4] kmemtrace: Core implementation., Pekka Enberg, (Mon Jul 28, 5:24 am)
Re: [RFC PATCH 1/4] kmemtrace: Core implementation., Mathieu Desnoyers, (Mon Jul 28, 12:29 pm)
Re: [RFC PATCH 1/4] kmemtrace: Core implementation., Eduard - Gabriel Munteanu..., (Mon Jul 28, 1:35 pm)
Re: [RFC PATCH 1/4] kmemtrace: Core implementation., Pekka Enberg, (Tue Jul 29, 4:25 am)
Re: [RFC PATCH 1/4] kmemtrace: Core implementation., Matt Mackall, (Mon Jul 28, 1:09 pm)
[RFC PATCH 2/4] kmemtrace: SLAB hooks., Eduard - Gabriel Munteanu..., (Tue Jul 22, 2:36 pm)
Re: [RFC PATCH 2/4] kmemtrace: SLAB hooks., Pekka Enberg, (Mon Jul 28, 5:37 am)
[RFC PATCH 3/4] kmemtrace: SLUB hooks., Eduard - Gabriel Munteanu..., (Tue Jul 22, 2:36 pm)
Re: [RFC PATCH 3/4] kmemtrace: SLUB hooks., Pekka Enberg, (Mon Jul 28, 5:40 am)
[RFC PATCH 4/4] kmemtrace: SLOB hooks., Eduard - Gabriel Munteanu..., (Tue Jul 22, 2:36 pm)
Re: [RFC PATCH 4/4] kmemtrace: SLOB hooks., Pekka Enberg, (Mon Jul 28, 5:41 am)
Re: [RFC PATCH 4/4] kmemtrace: SLOB hooks., Matt Mackall, (Tue Jul 22, 4:53 pm)
Re: [RFC PATCH 4/4] kmemtrace: SLOB hooks., Eduard - Gabriel Munteanu..., (Tue Jul 22, 5:07 pm)