[lkml]   [2010]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC GIT PULL] perf/trace/lock optimization/scalability improvements
    On Wed, Feb 03, 2010 at 11:33:16AM +0100, Peter Zijlstra wrote:
    > On Wed, 2010-02-03 at 10:14 +0100, Frederic Weisbecker wrote:
    > > - event injection support
    > I like the idea, I'm just not sure about the name and API details.
    > I would like to call it something like collection support, and the API
    > should have an iterator like interface.
    > That is, it should not blindly dump all events from a collection at
    > once, praying the output buffer is large enough, but either dump a
    > specified number and/or stop dumping when the buffer is full. Allowing a
    > second invocation to continue where it left off after the buffer content
    > has been consumed.

    Yeah I agree. But my worry is there are induced races in this scheme.
    But probably tight enough that we don't care much.

    Consider dumping the task list content:

    A -> B -> C -> D

    You open a "task" event. And ask to inject it one by one,
    you first dump A, and B disappear, then you'll miss it
    but you can still get C and D if they don't disappear.

    As I said it is tight enough that we don't care. If B disappears
    so early, it means it won't have a determinant role in the profiling
    anyway (at worst few isolated events in the beginning).

    The fact is the async injection will always have such misses by
    its nature anyway, you can still dump the whole at once, and you will
    miss events that just disappeared before the injection call, so whatever...

    > Which brings us to the ioctl() interface, we can do the above using
    > ioctl()s, but it seems to me we're starting to get ioctl() heavy and
    > should be looking at alternative ways of extending this.
    > Anybody any bright ideas?

    Using ioctl, we can basically have such structure:

    struct perf_inject_req {
    int start; (in)
    int len; (in)
    int *read; (out)

    Using an idx will often imply rewalk a whole object list from
    the beginning, which is perfectly fine.

    If you prefer an alternate syscall, I can make it. I've been
    told about ioctl drawbacks by the past, I personally think
    ioctl has not only drawbacks: it avoids a proliferation
    of syscalls. But that's how you prefer.

     \ /
      Last update: 2010-02-03 23:11    [W:0.026 / U:96.836 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site