[RFC PATCH] LTTng relay buffer allocation, read, write - Kernel

This is a discussion on [RFC PATCH] LTTng relay buffer allocation, read, write - Kernel ; Hi - On Tue, Sep 30, 2008 at 03:43:45PM -0400, Steven Rostedt wrote: > [...] > On Tue, 30 Sep 2008, Mathieu Desnoyers wrote: > > > > You are actually using them to put redundant information that could be ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 24 of 24

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

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

    Hi -

    On Tue, Sep 30, 2008 at 03:43:45PM -0400, Steven Rostedt wrote:
    > [...]
    > On Tue, 30 Sep 2008, Mathieu Desnoyers wrote:
    > >
    > > You are actually using them to put redundant information that could be
    > > encoded differently and thus save 4 bits per event records, more or less
    > > what will be needed by most tracers (15 IDs, 1 reserved for an extended
    > > ID field).

    >
    > I really like the idea of keeping the tracer event ids out of the ring
    > buffer logic.


    That's fine for a ring buffer that only ever contains data from one
    event source. How do you imagine multiplexing working, where one
    wants to grep a single debugfs file that contains data from different
    event sources? Punt to another layer?

    - FChE
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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


    On Tue, 30 Sep 2008, Frank Ch. Eigler wrote:
    > On Tue, Sep 30, 2008 at 03:43:45PM -0400, Steven Rostedt wrote:
    > > [...]
    > > On Tue, 30 Sep 2008, Mathieu Desnoyers wrote:
    > > >
    > > > You are actually using them to put redundant information that could be
    > > > encoded differently and thus save 4 bits per event records, more or less
    > > > what will be needed by most tracers (15 IDs, 1 reserved for an extended
    > > > ID field).

    > >
    > > I really like the idea of keeping the tracer event ids out of the ring
    > > buffer logic.

    >
    > That's fine for a ring buffer that only ever contains data from one
    > event source. How do you imagine multiplexing working, where one
    > wants to grep a single debugfs file that contains data from different
    > event sources? Punt to another layer?


    Field goal!

    Yes! That is exactly what I want. If your trace has only one event, why
    would it want to record them? The event id belongs in the tracer layer
    not the ring buffer layer.

    I would like to make a "trace_buffer" layer that includes all of this.

    -- Steve

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

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

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

    >> 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.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    * 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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2