Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
posting.
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 +
csa_patch_jlan

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


<snip>

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.

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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux