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

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