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

[Jay Lan <jlan@sgi.com>]

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.

Agreed.

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

I do not see impacts of both cases above since it would not happen.
I expect the event of turning off taskstats feature is coordidated
by the system adminstrator, so all users are notified in advance.

For that reason, i think exposing the switch at sysfs is not a good
idea. Instead, /etc/init.d/taskstats script would be right for
this purpose. At kernel side, we would need to make this possible.

What do you think?

Regards,
  - jay

> 
> 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 ?
> 
> --Shailabh
> 
> 
> 
> 
> 
> 
> 
>