Messages in this thread | | | Date | Thu, 15 Jun 2006 11:57:05 -0700 | From | Jay Lan <> | Subject | Re: ON/OFF control of taskstats accounting data at do_exit |
| |
Balbir Singh wrote: > >> 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. > > > When you say we need to make this possible at the kernel side, do you > want the kernel not to accumulate taskstats in the do_exit() path > (avoid calling fill_xxxx routines) if there are no listeners > on TASKSTATS_LISTEN_GROUP? As Shailabh, mentioned sending out does not > happen if there are no listeners.
I did not understand that when i made the request because i did not see from taskstats code how you can control that. Shailabh later said that it was done at netlink layer.
I do not know how deep down in netlink layer to exit the proces, but it may turn out that the need of this feature not that importan...
Yet, we still allocate memory, fill taskstats struct, invoke netlink, and free memory. Ideally when taskstats is turned off, we do not need to do any of these. So, if we can fail memory allocation when taskstats is turned off, the taskstats_exit_send() will return right away.
To answer Shailabh's discussion in a separate email, yes, i meant the second case that all taskstats applications will be stopped or suspended. The different between a /etc/init.d/taskstats and a sysfs/procfs control of taskstats is that the system will not be activated at init time. However, i admit customers can always turn off taskstats via sysfs before starts whatever they like to do.
I do not know what is community's preference: a /etc/init.d mechnism or a sysfs mechnism. I would be happy either way. Thanks!
Regards, jay
> >> >> What do you think? >> >> Regards, >> - jay >>
- 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/
| |