LWN: Comments on "Low-level tracing plumbing"

Right-shifted

sethml — 2008-10-10T20:46:07+00:00

It depends on what the meaning of "is" is. :)

Something like "the len field contains the length with the two lowest bits lopped off" would
be clearer.

Re: the side note

dw — 2008-10-05T20:48:58+00:00

Turns out there are good reasons not to go with C99 stdint types in the kernel (namespace issues). Thread starting here.

I'm no hardware nut, but..

fuhchee — 2008-10-03T23:43:29+00:00

> It could still be kernel code doing the unpacking, just not at trace-time.

If the kernel isn't going to host huge history buffers, then
conversions will in general have to be done essentially online,
probably deferred only a bit.

I'm no hardware nut, but..

tbird20d — 2008-10-03T23:31:35+00:00

It could still be kernel code doing the unpacking, just not at trace-time. This preserves the ability to use cat & grep, while still omitting the unpacking overhead during trace itself.

Right-shifted

ndk — 2008-10-03T18:53:45+00:00

Yep, I misread what you wrote.

Right-shifted

corbet — 2008-10-03T04:00:00+00:00

In fact, the value stored in len has indeed been right-shifted by two bits. It needs to be left-shifted to be interpreted. Apologies if I wrote it in a way that was less than entirely clear, but I believe it was correct.

Low-level tracing plumbing

ndk — 2008-10-02T22:12:59+00:00

> a length given by the len field, which is right-shifted by two bits

should read "left-shifted".

I'm no hardware nut, but..

fuhchee — 2008-10-02T21:51:36+00:00

> Not only that, but it'll possibly be just the packing. Unpacking and
> collating data can be done in userspace, and possibly offline after enough
> trace data's been collected.

OTOH, Linus wanted to people to be able to use this tracing stuff with
just a cat/grep, which seems to eschew *requiring* special userspace tools
for unpacking.

I'm no hardware nut, but..

Oddscurity — 2008-10-02T17:01:33+00:00

Not only that, but it'll possibly be just the packing. Unpacking and collating data can be done in userspace, and possibly offline after enough trace data's been collected.

Having dense fields like this also means a lot more of these will fit in cache.

I'm no hardware nut, but..

xav — 2008-10-02T09:35:29+00:00

Nowadays, optimizing for size is what counts the most. The few cycles you spend at packing and unpacking data (or recomputing it in some cases) are well repaid by the huge number of cycles waiting for the memory controller you gained.

I'm no hardware nut, but..

mbligh — 2008-10-02T03:51:19+00:00

> It seems to me that the struct is better optimised for size than it is
> performance.

Yes. We want to pack as much data into the buffer as possible

> struct { uint32_t; uint32_t; uint32_t; }

That takes 3 times as much space! You're roughly having the amount of useful
data we can store in the trace buffer.

> struct { uint8_t; uint8_t; uint16_t; }

That doesn't leave enough space for the time counter. It's TSC stamping at roughly 2-4GHz, and we need accurate resolution to merge the per-cpu buffers back together. We don't want to log extended timestamp events (whenever your time counter rolls over) too often.

I'm no hardware nut, but..

felixfix — 2008-10-02T02:52:07+00:00

I'd guess it's better to have more events or to use less memory for the same number of events. The few cycles spent twiddling bits are a much better bargain than eating up memory, and will pay for themselves in reduced memory impact anyway. I have written (long long ago) similar traces and my primary goal was ALWAYS as many trace events as possible.

I'm no hardware nut, but..

dw — 2008-10-02T01:45:08+00:00

It seems to me that the struct is better optimised for size than it is performance. Can gcc really generate speedy code for those kinds of odd shaped bitfields?

I'd have thought either of these would be faster:

struct { uint32_t; uint32_t; uint32_t; }
struct { uint8_t; uint8_t; uint16_t; }

Side note: has there been any discussion of moving the kernel to the use of C99 fixed-width integer types? It's only been almost a decade. Having worked on a C99 project for a while, the in-kernel type names now look pesky. :)

Looking at (unoptimised Apple) gcc 4 output makes me think the struct from the article may not be so optimal.. http://pastebin.com/f33132559