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 ?
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.
So, are we trying to solve a real problem ?
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 [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]