I'm no hardware nut, but.. [LWN.net]

I'm no hardware nut, but..

Posted Oct 2, 2008 1:45 UTC (Thu) by dw (guest, #12017)
Parent article: Low-level tracing plumbing

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

I'm no hardware nut, but..

Posted Oct 2, 2008 3:51 UTC (Thu) by mbligh (subscriber, #7720) [Link]

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

Posted Oct 2, 2008 9:35 UTC (Thu) by xav (guest, #18536) [Link] (4 responses)

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

Posted Oct 2, 2008 17:01 UTC (Thu) by Oddscurity (guest, #46851) [Link] (3 responses)

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

Posted Oct 2, 2008 21:51 UTC (Thu) by fuhchee (guest, #40059) [Link] (2 responses)

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

Posted Oct 3, 2008 23:31 UTC (Fri) by tbird20d (subscriber, #1901) [Link] (1 responses)

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.

I'm no hardware nut, but..

Posted Oct 3, 2008 23:43 UTC (Fri) by fuhchee (guest, #40059) [Link]

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

Re: the side note

Posted Oct 5, 2008 20:48 UTC (Sun) by dw (guest, #12017) [Link]

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