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
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
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
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
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
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
> 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
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
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
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
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
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
+
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
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
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
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
16 matches
Mail list logo