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

[Shailabh Nagar]

Jay Lan wrote:
> Shailabh Nagar wrote:

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

Agreed that all users will be notified. Once that happens, what do you expect
these users will do to the applications they are running that
a) query per-task data periodically, or
b) monitor exit data

Either these applications will continue running (querying, listening) and
have to understand that they cannot expect more data
or they will be stopped(or suspended) from doing the monitoring/querying.

If its the latter, then we don't really need kernel changes since we only save on
a little bit of assembling data overhead.

If its the former, then yes, it will be useful to have the kernel changes.

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

I don't get the difference between these two options as far as kernel is concerned.
A systemwide switch that can be set by only by a privileged user is what is needed
either way, right ? Whether it is in sys/kernel (through sysfs) or
/proc/sys/kernel (through /proc and via sysctl) ? Or is there something else that an
/etc/init.d/taskstats script can do to set a kernel parameter ?


> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/