Re: [UPDATED PATCH] Re: [Lse-tech] Re: [Patch 7/7] Generic netlink interface (delay accounting)

2006-03-13 Thread Balbir Singh
On Sat, Mar 11, 2006 at 08:30:49AM -0500, jamal wrote: > On Fri, 2006-10-03 at 22:09 +0530, Balbir Singh wrote: > > On Fri, Mar 10, 2006 at 09:53:53AM -0500, jamal wrote: > > > > On kernel->user (in the case of response to #a or async notifiation as > > > in #b) you really dont need to specify th

Re: [UPDATED PATCH] Re: [Lse-tech] Re: [Patch 7/7] Generic netlink interface (delay accounting)

2006-03-11 Thread jamal
On Fri, 2006-10-03 at 22:09 +0530, Balbir Singh wrote: > On Fri, Mar 10, 2006 at 09:53:53AM -0500, jamal wrote: > > On kernel->user (in the case of response to #a or async notifiation as > > in #b) you really dont need to specify the TG/PID since they appear in > > the STATS etc. > > I see your

Re: [UPDATED PATCH] Re: [Lse-tech] Re: [Patch 7/7] Generic netlink interface (delay accounting)

2006-03-10 Thread Balbir Singh
On Fri, Mar 10, 2006 at 09:53:53AM -0500, jamal wrote: > On Thu, 2006-09-03 at 20:07 +0530, Balbir Singh wrote: > > Please let us know if we missed something out. > > Design still shaky IMO - now that i think i may understand what your end > goal is. > Using the principles i described in earlier

Re: [UPDATED PATCH] Re: [Lse-tech] Re: [Patch 7/7] Generic netlink interface (delay accounting)

2006-03-10 Thread jamal
On Fri, 2006-10-03 at 09:53 -0500, jamal wrote: > > a) shipping of the taskstats from kernel to user-space asynchronously to > all listeners on multicast channel/group TASKSTATS_LISTEN_GRP > at the point when some process exits. > b) responding to queries issued by the user to the kernel for task

Re: [UPDATED PATCH] Re: [Lse-tech] Re: [Patch 7/7] Generic netlink interface (delay accounting)

2006-03-10 Thread jamal
On Thu, 2006-09-03 at 20:07 +0530, Balbir Singh wrote: > Please find the latest version of the patch for review. The genetlink > code has been updated as per your review comments. The changelog is provided > below > > 1. Eliminated TASKSTATS_CMD_LISTEN and TASKSTATS_CMD_IGNORE > 2. Provide generi

Re: [UPDATED PATCH] Re: [Lse-tech] Re: [Patch 7/7] Generic netlink interface (delay accounting)

2006-03-09 Thread Shailabh Nagar
Balbir Singh wrote: Hello, Jamal, Please find the latest version of the patch for review. The genetlink code has been updated as per your review comments. The changelog is provided below 1. Eliminated TASKSTATS_CMD_LISTEN and TASKSTATS_CMD_IGNORE 2. Provide generic functions called genlmsg_d

[UPDATED PATCH] Re: [Lse-tech] Re: [Patch 7/7] Generic netlink interface (delay accounting)

2006-03-09 Thread Balbir Singh
> Thanks for the clarification of the usage model. While our needs are > certainly much less complex, > it is useful to know the range of options. > > >There are no hard rules on what you need to be multicasting and as an > >example you could send periodic(aka time based) samples from the kernel

Re: [Lse-tech] Re: [Patch 7/7] Generic netlink interface (delay accounting)

2006-03-08 Thread Shailabh Nagar
jamal wrote: On Mon, 2006-06-03 at 12:00 -0500, Shailabh Nagar wrote: My design was to have the listener get both responses (what I call replies in the code) as well as events (data sent on exit of pid) I think i may not be doing justice explaining this, so let me be more elaborate

Re: [Lse-tech] Re: [Patch 7/7] Generic netlink interface (delay accounting)

2006-03-07 Thread jamal
On Mon, 2006-06-03 at 12:00 -0500, Shailabh Nagar wrote: > My design was to have the listener get both responses (what I call > replies in the code) as well as events (data sent on exit of pid) > I think i may not be doing justice explaining this, so let me be more elaborate so we can be in syn

Re: [Patch 7/7] Generic netlink interface (delay accounting)

2006-03-06 Thread Shailabh Nagar
Jamal, Pls keep lkml and lse-tech on cc since some of this affects the usage of delay accounting. jamal wrote: Hi Shailabh, Apologies for taking a week to respond .. On Mon, 2006-27-02 at 15:26 -0500, Shailabh Nagar wrote: jamal wrote: Yes, the current intent is to allow multi

Re: [Patch 7/7] Generic netlink interface (delay accounting)

2006-03-06 Thread jamal
Hi Shailabh, Apologies for taking a week to respond .. On Mon, 2006-27-02 at 15:26 -0500, Shailabh Nagar wrote: > jamal wrote: > Yes, the current intent is to allow multiple listeners to receive the > responses sent by the kernel. Responses or events? There is a difference: Response implies th

Re: [Patch 7/7] Generic netlink interface (delay accounting)

2006-02-27 Thread Shailabh Nagar
jamal wrote: + +/* + * Commands sent from userspace + * Not versioned. New commands should only be inserted at the enum's end + */ + +enum { + TASKSTATS_CMD_UNSPEC, /* Reserved */ + TASKSTATS_CMD_NONE, /* Not a valid cmd to send +

Re: [Patch 7/7] Generic netlink interface (delay accounting)

2006-02-27 Thread Shailabh Nagar
jamal wrote: On Mon, 2006-27-02 at 03:31 -0500, Shailabh Nagar wrote: +#define TASKSTATS_LISTEN_GROUP 0x1 You do multicast to this group - does this mean there could be multiple listeners subscribed for this event? Yes, the current intent is to allow multiple listeners to receive

Re: [Patch 7/7] Generic netlink interface (delay accounting)

2006-02-27 Thread jamal
On Mon, 2006-27-02 at 07:59 -0500, jamal wrote: > you should meant should not. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [Patch 7/7] Generic netlink interface (delay accounting)

2006-02-27 Thread jamal
On Mon, 2006-27-02 at 03:31 -0500, Shailabh Nagar wrote: > +#define TASKSTATS_LISTEN_GROUP 0x1 You do multicast to this group - does this mean there could be multiple listeners subscribed for this event? How does this correlate to TASKSTATS_CMD_LISTEN/IGNORE? Typically, an equivalent of li

[Patch 7/7] Generic netlink interface (delay accounting)

2006-02-27 Thread Shailabh Nagar
delayacct-genetlink.patch Create a generic netlink interface (NETLINK_GENERIC family), called "taskstats", for getting delay and cpu statistics of tasks and thread groups during their lifetime and when they exit. The cpu stats are available only if CONFIG_SCHEDSTATS is enabled. When a task is