[lkml]   [2006]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats
    Jay Lan wrote:

    >Jay Lan wrote:
    >>Shailabh Nagar wrote:
    >>>Andrew Morton wrote:
    >>>>You see the problem - if one userspace package wants the tgid-stats and
    >>>>another concurrently-running one does now, what do we do? Just leave it
    >>>>enabled and run a bit slower?
    >>>>If so, how much slower? Your changelog says some potential users don't
    >>>>need the tgid-stats, but so what? I assume this patch is a performance
    >>>>thing? If so, has it been quantified?
    >>>Here are some results from running a simple program (source below) that does
    >>>10 iterations of creating and then destroying 1000 threads. On the side, another utility
    >>>kept reading the pid (+tgid if present) stats from exiting tasks.
    >>I ran my testing using the same program posted by Shalilabh attached in his
    Thanks for running this. The results look interesting.

    >>System: SGI a350, a two cpus IA64 machine.
    >>Kernel: 2.6.17-rc3 + delay-acct-taskstats patch set
    >> + tgid-disable_patch_shailabh + exit race patch_balbir +
    >>I also modified the Decumentation/accounting/getdelay.c:
    >> - it repeatedly does recv() to retrieve data from kernel
    >> - instead of using printf() to display data received, i simply write
    >>it to
    >> disk as it would be for an accounting daemon. Note that currently
    >>both the
    >> BSD (or GNU) accounting and the CSA writes accounting data from kernel.
    >> As an effort of moving accounting system to userspace, the raw data
    >> to be written to a raw file first before further processing.
    In exit_recv.c, you appear to be dumping the per-tgid data received to
    disk too ?
    If the accounting daemon isn't interested in per-tgid, shouldn't it be
    discarding the data immediately after
    doing the recv() and only write to disk the data it wants ?
    Perhaps I'm missing something.


    >>Another observation that i considered bad news is that all
    >>10 runs produced 1 to 5 recv() error with errno=105 (ENOBUF).
    Wonder if this has to do with userspace not being able to keep up with
    the data flow because
    of the pathological rate at which exits happen.

    Anyway, lets look at the overhead part first perhaps.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-06-21 21:38    [W:0.024 / U:51.244 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site