Re: ON/OFF control of taskstats accounting data at do_exit

[Peter Williams <pwil3058@bigpond.net.au>]

Shailabh Nagar wrote:
> Jay Lan wrote:
>
>
> > I was talking about turning off system-wise taskstats data preparation and
> > delivery when every task exits. Sometimes customers like to do some
> > benchmarking and need to turn off nonessential features.
>
> Lets go through the implications of turning on/off collection, assembly and delivery
> of the per-task accounting data.
>
> Collection is defined by different subsystems using taskstats.
> For atleast one of these (delay accounting), turning on/off dynamically has been tried
> and deemed to cause a lot of overhead (due to accumalated nature of data) and also be
> prone to races. Complexity of code added did not justify the value so on/off was restricted
> to a boot time decision.
>
> Assembly and delivery of data is done by the taskstats code, calling subsystem-specific functions to fill
> the commonly used struct taskstats and relying on genetlink to do the delivery.
> This can be turned on/off using a dynamic parameter such as /sys/kernel/taskstats_enable which sets
> some internal variable that is used to do early exits from relevant functions (mainly taskstats_send_stats
> and taskstats_exit_send)
> Doing so will have impact on
> a) queries sent to the kernel by monitoring applications
> b) task exit data sent by kernel to apps listening on the multicast socket
>
> For consistency, I'm assuming both a) and b) will have to be affected when taskstats is turned off.
> Also, I'm assuming monitoring applications aren't aware of the turn off.
>
> What happens to case a) ? Apps will need to get some error message as a reply. Some assembly overhead
> is saved (since such an error reply can be sent right away as soon as a query command is seen) but no
> substantial saving on the delivery part.
>
> For case b), we can save on assembly and delivery by exiting early from taskstats_exit_send(). But won't
> we need to send some message (if not periodically, atleast once) to listening apps that they shouldn't
> expect any exit data ? Semantics of suddenly not seeing any exit data could be misinterpreted ?
>
> Its easy enough to implement...just concerned about the semantics of doing so (as far as userspace
> apps are concerned) and utility in general settings. Utility in case where only CSA is running (delay
> accounting and other users turned off) is clear.
>
> Thoughts ?

I would have thought that it was obvious that turning on/off the 
collection of statistics concerning the ACCRUED time that tasks spend in 
various states (which is what we're talking about) would cause the data 
to be horribly corrupted.

I also suspect that the overhead of the tests associated with checking 
whether the mechanism is on or off is probably almost as big as the 
overhead of gathering the statistics anyway.  Assuming that the clock 
time is already available (true for most places in the CPU scheduler 
where you'd want to gather stats, for one) the cost of gathering the 
stats is a subtraction, an addition and (possibly) an assignment to a 
time stamp (I say possibly here as you may get the time stamp updated 
for free as well).

Peter
--
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce
-
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/