Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats

Jay Lan
2006-06-29T21:55:11Z

Shailabh Nagar wrote:
> Paul Jackson wrote:
>
>> Shailabh wrote:
>>
>>
>>> I suppose this is because cpuset's offer some middle ground between
>>> collecting data per-cpu vs. collecting it for all cpus ?
>>>
>>
>>
>> Yes - well said. And I have this strange tendency to see all the
>> worlds problems as opportunities for cpuset solutions <grin>.
>>
>>
>>
>>> What happens when someone is using cpusets on such a machine and
>>> changes its membership in response to other needs. All taskstats
>>> users would need to monitor for such changes and adjust their
>>> processing....seems like unnecessary tying up of two unrelated
>>> concepts.
>>>
>>
>>
>> I would not expect taskstat users to monitor for such changes.
>> I'd expect them to monitor the stats from whatever is in the
>> cpuset they named. If a task moves out of that cpuset to another,
>> then tough -- that task will no longer be monitored by that
>> particular monitoring request.
>>
>> Cpusets do provide a convenient middle ground, as you say, which
>> is really useful for reducing scaling issues such as this one to
>> a managable size.
>>
>> Per-cpu is too fine grained, and per-system too coarse.
>>
>> An unnecessary tying - yes. But perhaps a useful one.
>>
>>
> The idea of collecting stats for a group of cpus rather than all (or
> one) seems attractive.
> But cpusets doesnt :-)
>
> How about if we did something simple like
> having a separate listen group (within genetlink) for a reasonably large
> number of cpus
> and have all the messages from those cpus multicast to the listeners of
> that group alone ?
>
> e.g. currently we have only one TASKSTATS_LISTEN_GROUP
> we could reserve the following
> TASKSTATS_LISTEN_GROUP_0
> TASKSTATS_LISTEN_GROUP_1....
>
> where GROUP_0 handles cpus numbered 0-63 (or 31)....etc.
>
> Advantages would be
>
> 1. Most users would still need to listen to the one group as they do
> in the current design and others could listen to more, scaling up their
> userspace listening daemons
> as appropriate (e.g. one daemon per listening group).
>
> 2. Userspace could be saved the bother of having too many streams of
> per-cpu data and reassemble them
> in the order they were generated.
>
> The moment we talk of splitting up the data stream generated by the
> kernel I suppose we have to do some
> kind of timestamping so reassembly in the same order can be done. I
> can't see this mattering for the likes of
> delay accounting and CSA but for future taskstats users, who knows.

Timestamp of the taskstats messages or timestamp of the exiting task?
I include an exit_time field for the task as part of "Common
Accounting Fields" in my csa_taskstats patch i sent to you. So, we
have both start_time and exit_time.

Thanks,
- jay

>
>
> --Shailabh
>
>