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

[Shailabh Nagar]

jamal wrote:
> On Mon, 2006-03-07 at 18:01 -0700, Andrew Morton wrote:
>
> > On Mon, 03 Jul 2006 20:54:37 -0400
> > Shailabh Nagar <nagar@xxxxxxxxxxxxxx> wrote:
> >
> >
> > > > What happens when a listener exits without doing deregistration
> > > > (or if the listener attempts to register another cpumask while a current
> > > > registration is still active).
> > >
> > > ( Jamal, your thoughts on this problem would be appreciated)
> > >
> > > Problem is that we have a listener task which has "registered" with 
> > > taskstats and caused
> > > its pid to be stored in various per-cpu lists of listeners. Later, when 
> > > some other task exits on a given cpu, its exit data is sent using 
> > > genlmsg_unicast on each pid present on that cpu's list.
> > >
> > > If the listener exits without doing a "deregister", its pid continues to 
> > > be kept around, obviously not a good thing. So we need some way of 
> > > detecting the situation (task is no longer listening on
> > > these cpus events) that is efficient.
> >
> > Also need to address the case where the listener has closed off his file
> > descriptor but continues to run.
> >
> > So hooking into listener's exit() isn't appropriate - the teardown is
> > associated with the lifetime of the fd, not of the process.  If we do that,
> > exit() gets handled for free.  
>
>
> If you are always going to send unicast messages, then  -ECONNREFUSED
> will tell you the listener has closed their fd - this doesnt meant it
> has exited. 

Thats good. So we have atleast one way of detecting the "closed fd without
deregistering" within taskstats itself.

> Besides that one process could open several sockets. I know
> that would not be the app you would write - but it doesnt stop other
> people from doing it.

As far as API is concerned, even a taskstats listener is not being
prevented from opening multiple sockets. As Andrew also pointed out,
everything needs to be done per-socket.

> I think i may not follow what you are doing - for some reason i thought
> you may have many listeners in user space and these messages get
> multicast to them?

That was the design earlier. In the past week, the design has changed to
one where there are still many listeners in user space but messages
get unicast to each of them. Earlier listeners would get messages generated
on task exit from every cpu, now they get it only from cpus for which
they have explicitly registered interest (via a cpumask passed in through
another genetlink command).

> Does the user space program somehow communicate its pid to the kernel?

Yes. When the listener registers interest in a set of cpus, as described
above, its (genl_info->pid) is being stored in the per-cpu list of
listeners for those cpus. When a task exits on one of those cpus, the
exit data is only sent via genetlink_unicast to those pids
(really, nl_pids) who are on that cpu's listener list.


Now that I think more about it, netlink is really maintaining a pidhash
of nl_pids, not process pids, right ? So if one userapp were to open
multiple sockets using NETLINK_GENERIC protocol (regardless of how many
of those are for the taskstats), each of them would have to use a
different nl_pid. Hence, it would be valid for the taskstats layer to use 
netlink_lookup() at any time to see if the corresponding socket were
closed ?


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