Jay Lan wrote:
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.
You're right..I am mixing the two..but only to show to make the point that
anyway clients have to deal with extra data they don't care about. As
long as the performance overhead
of that isn't significant, its not an issue.
Also, unlike, shared taskstats structure, discarding the excess per-tgid
data is even easier
because it comes in its own netlink attribute.
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.
Fair enough. So lets see what the excess 168 bytes does in terms of
perf and make a determination
based on that ?
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?
Yes...but I don't see the point ? If exits happen at a very slow rate,
then the performance impact will drop
compared to if they happen at the insane rate in the toy program. So
rate of exit is a factor..or did I not
get your point ?
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.
Sounds good. Please share asap so that 2.6.18 acceptance isn't held up.
Regards,
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]
