Re: [RFC PATCH] LTTng relay buffer allocation, read, write

[Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>]

* Martin Bligh (mbligh@google.com) wrote:
> > I am not saying anything about the actual number of events with 0 bytes
> > payload I actually have in my own instrumentation, if this is what you
> > mean. I am just saying that it leaves this room available for such
> > events.
> 
> It would, yes. Are they useful?
> 

Stuff like irq_exit has 0 byte payload, is very high rate, and useful,
yes.

> > Even if there is a 32 bits payload associated with those events, the
> > fact that we can encode the event ID in the 32 bits header will bring
> > those events from 96 bits (due to 32 bits alignment) down to 64 bits.
> 
> That's true. So do we have a bunch of stuff that we really really need
> that'd fit into 32 bits, but not 28 bits?
> 

Probably pointers on 32 bits archs. Any "int" value, on 32 or 64 bits,
will need careful attention if we want only to export the 28 LSBs. It
would probably make error value export a bit trickier and error-prone.


> >> This is all over 1 bit of information, right? Since you need at least 1 for
> >> the timestamp stuff.
> >
> > 4 bits of information could be added to the 32-bits header if we allow
> > tracers to register their first 15 event IDs in those 4 bits.
> >
> > But well... let's keep that for v2. ;)
> 
> Sounds like a plan ;-) All this stuff is internal representations anyway.


Yup.

Mathieu

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68