Messages in this thread | | | Date | Thu, 15 Jun 2006 10:24:35 -0700 | From | Jay Lan <> | Subject | Re: ON/OFF control of taskstats accounting data at do_exit |
| |
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 > > > > > > > >
- 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/
| |