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

[Shailabh Nagar <nagar@watson.ibm.com>]

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.


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