Messages in this thread | | | Date | Mon, 12 Jun 2006 11:31:37 -0700 | From | Jay Lan <> | Subject | Re: [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/
| |