lkml.org 
[lkml]   [2006]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats
Shailabh Nagar wrote:
> Jay Lan wrote:
>
>> Andrew Morton wrote:
>>
>>
>>
>
>>> But the overhead at present is awfully low. If we don't need this
>>> ability
>>> at present (and I don't think we do) then a paper design would be
>>> sufficient at this time. As long as we know we can do this in the
>>> future
>>> without breaking existing APIs then OK.
>>>
>>>
>>
>> i can see if an exiting process is the only process in the thread group,
>> the (not is_thread_group) condition would be true. So, that leaves
>> multi-threaded applications that are not interested in tgid-data still
>> receive 2x taskstats data.
>>
>>
> Jay,
>
> Why is the 2x taskstats data for the multithreaded app a real problem ?
> When differnt clients agree to use a common taskstats structure, they
> also incur the potential
> overhead of receiving extra data they don't really care about (in CSA's
> case, that would be all the
> delay accounting fields of struct taskstats). Isn't that, in some sense,
> the "price" of sharing a structure
> or delivery mechanism ?

You are mixing the two types of overhead: 1) overhead due to tgid,
2) overhead due to extra fields of struct taskstats they don't care
about.

The type 2 overhead for CSA is very small, but is bigger for you. In our
discussion earlier, i told you (and you accpeted) that i will insert
128 bytes of data into taskstat struct. I have not finalized the CSA
work yet, but it can be 168 additional bytes or close to that number:

/* Common Accounting Fields start */
u32 ac_uid; /* User ID */
u32 ac_gid; /* Group ID */
u32 ac_pid; /* Process ID */
u32 ac_ppid; /* Parent process ID */
struct timespec start_time; /* Start time */
struct timespec exit_time; /* Exit time */
u64 ac_utime; /* User CPU time [usec] */
u64 ac_stime; /* SYstem CPU time [usec] */
/* Common Accounting Fields end */

/* CSA accounting fields start */
u64 ac_sbu; /* System billing units */
u16 csa_revision; /* CSA Revision */
u8 csa_type; /* Record types */
u8 csa_flag; /* Record flags */
u8 ac_stat; /* Exit status */
u8 ac_nice; /* Nice value */
u8 ac_sched; /* Scheduling discipline */
u8 pad0; /* Unused */
u64 acct_rss_mem1; /* accumulated rss usage */
u64 acct_vm_mem1; /* accumulated virtual memory
usage */
u64 hiwater_rss; /* High-watermark of RSS usage
*/
u64 hiwater_vm; /* High-water virtual memory
usage */
u64 ac_minflt; /* Minor Page Fault */
u64 ac_majflt; /* Major Page Fault */
u64 ac_chr; /* bytes read */
u64 ac_chw; /* bytes written */
u64 ac_scr; /* read syscalls */
u64 ac_scw; /* write syscalls */
u64 ac_jid; /* Job ID */
/* CSA accounting fields end */

This is type 2 overhead. The bigger overhead in type 2, the bigger
impact of sending tgid data is bigger.

>
> Of course, if this overhead becomes too much, we need to find
> alternatives. But, as already shown,
> even in the extreme case where app does nothing but fork/exit, there is
> very
> little performance impact. So I don't see how in the common case of
> multithreaded apps, where exits
> are going to be at a far lesser rate, the extra per-tgid data is a real
> issue.

Yes, application handles "real" work between fork and exit. But,
each task within a thread group still trigger do_exit on termination,
right?

>
> So, are we trying to solve a real problem ?

I do not know, but i am concerned. I will run some testing with the
taskstats struct above and get some data.

Thanks,
- jay


>
> I'll address the alternatives in a separate mail but lets address this
> point first please.
>
> --Shailabh

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

\
 
 \ /
  Last update: 2006-06-12 20:34    [W:0.280 / U:0.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site