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

[Jay Lan <jlan@sgi.com>]

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