Re: [PATCH] per-task delay accounting taskstats interface: control exit data through cpumasks]

2006-07-07 Thread Thomas Graf
* Andrew Morton <[EMAIL PROTECTED]> 2006-07-06 15:56 > Yup. Thomas, what's the testing status of the netlink patch you sent? > Should I > queue it up and start plagueing people with it? It survived feeding it with oversized strings etc. Feel free to queue it up. - To unsubscribe from this list:

Re: [PATCH] per-task delay accounting taskstats interface: control exit data through cpumasks]

2006-07-07 Thread Thomas Graf
* Andrew Morton <[EMAIL PROTECTED]> 2006-07-06 16:05 > hm, nla_strlcpy() looks more complex than it needs to be. We really need > nla_kstrndup() ;) > > Oh well. This? Looks good. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] Mo

Re: [PATCH] per-task delay accounting taskstats interface: control exit data through cpumasks]

2006-07-06 Thread Paul Jackson
Andrew wrote: > Your email client performs space-stuffing. Shailabh, Some of us find that it is easier and more reliable to use a special purpose script to send patches, rather than trying to do so via our email client. Even though my email client, Sylpheed, probably sends patches just fine, I e

Re: [PATCH] per-task delay accounting taskstats interface: control exit data through cpumasks]

2006-07-06 Thread Andrew Morton
Thomas Graf <[EMAIL PROTECTED]> wrote: > > * Andrew Morton <[EMAIL PROTECTED]> 2006-07-06 14:48 > > In the interests of keeping this work decoupled from netlink enhancements > > I'd propose the below. Is it bad to modify the data at nla_data()? > > Yes, it points into a skb data buffer which may

Re: [PATCH] per-task delay accounting taskstats interface: control exit data through cpumasks]

2006-07-06 Thread Andrew Morton
Shailabh Nagar <[EMAIL PROTECTED]> wrote: > > Andrew Morton wrote: > > Thomas Graf <[EMAIL PROTECTED]> wrote: > > > >>* Shailabh Nagar <[EMAIL PROTECTED]> 2006-07-06 07:37 > >> > >>>@@ -37,9 +45,26 @@ static struct nla_policy taskstats_cmd_g > >>> __read_mostly = { > >>> [TASKSTATS_CMD_ATTR_PID]

Re: [PATCH] per-task delay accounting taskstats interface: control exit data through cpumasks]

2006-07-06 Thread Thomas Graf
* Andrew Morton <[EMAIL PROTECTED]> 2006-07-06 14:48 > In the interests of keeping this work decoupled from netlink enhancements > I'd propose the below. Is it bad to modify the data at nla_data()? Yes, it points into a skb data buffer which may be shared by sitting on other queues if the message

Re: [PATCH] per-task delay accounting taskstats interface: control exit data through cpumasks]

2006-07-06 Thread Shailabh Nagar
Andrew Morton wrote: > Thomas Graf <[EMAIL PROTECTED]> wrote: > >>* Shailabh Nagar <[EMAIL PROTECTED]> 2006-07-06 07:37 >> >>>@@ -37,9 +45,26 @@ static struct nla_policy taskstats_cmd_g >>> __read_mostly = { >>> [TASKSTATS_CMD_ATTR_PID] = { .type = NLA_U32 }, >>> [TASKSTATS_CMD_ATTR_TGID]

Re: [PATCH] per-task delay accounting taskstats interface: control exit data through cpumasks]

2006-07-06 Thread Andrew Morton
Thomas Graf <[EMAIL PROTECTED]> wrote: > > * Shailabh Nagar <[EMAIL PROTECTED]> 2006-07-06 07:37 > > @@ -37,9 +45,26 @@ static struct nla_policy taskstats_cmd_g > > __read_mostly = { > > [TASKSTATS_CMD_ATTR_PID] = { .type = NLA_U32 }, > > [TASKSTATS_CMD_ATTR_TGID] = { .type = NLA_U32 }, >

Re: [PATCH] per-task delay accounting taskstats interface: control exit data through cpumasks]

2006-07-06 Thread Shailabh Nagar
On Thu, 2006-07-06 at 14:08 +0200, Thomas Graf wrote: > * Shailabh Nagar <[EMAIL PROTECTED]> 2006-07-06 07:37 > > @@ -37,9 +45,26 @@ static struct nla_policy taskstats_cmd_g > > __read_mostly = { > > [TASKSTATS_CMD_ATTR_PID] = { .type = NLA_U32 }, > > [TASKSTATS_CMD_ATTR_TGID] = { .type =

Re: [PATCH] per-task delay accounting taskstats interface: control exit data through cpumasks]

2006-07-06 Thread Thomas Graf
* Shailabh Nagar <[EMAIL PROTECTED]> 2006-07-06 07:37 > @@ -37,9 +45,26 @@ static struct nla_policy taskstats_cmd_g > __read_mostly = { > [TASKSTATS_CMD_ATTR_PID] = { .type = NLA_U32 }, > [TASKSTATS_CMD_ATTR_TGID] = { .type = NLA_U32 }, > + [TASKSTATS_CMD_ATTR_REGISTER_CPUMASK] =

Re: [PATCH] per-task delay accounting taskstats interface: control exit data through cpumasks]

2006-07-06 Thread Shailabh Nagar
On systems with a large number of cpus, with even a modest rate of tasks exiting per cpu, the volume of taskstats data sent on thread exit can overflow a userspace listener's buffers. One approach to avoiding overflow is to allow listeners to get data for a limited and specific set of cpus. By sc

Re: [PATCH] per-task delay accounting taskstats interface: control exit data through cpumasks]

2006-07-06 Thread Shailabh Nagar
On Thu, 2006-07-06 at 02:56 -0700, Andrew Morton wrote: > On Thu, 06 Jul 2006 05:28:35 -0400 > Shailabh Nagar <[EMAIL PROTECTED]> wrote: > > > On systems with a large number of cpus, with even a modest rate of > > tasks exiting per cpu, the volume of taskstats data sent on thread exit > > can over

Re: [PATCH] per-task delay accounting taskstats interface: control exit data through cpumasks]

2006-07-06 Thread Andrew Morton
On Thu, 06 Jul 2006 05:28:35 -0400 Shailabh Nagar <[EMAIL PROTECTED]> wrote: > On systems with a large number of cpus, with even a modest rate of > tasks exiting per cpu, the volume of taskstats data sent on thread exit > can overflow a userspace listener's buffers. > > One approach to avoiding o

[PATCH] per-task delay accounting taskstats interface: control exit data through cpumasks]

2006-07-06 Thread Shailabh Nagar
On systems with a large number of cpus, with even a modest rate of tasks exiting per cpu, the volume of taskstats data sent on thread exit can overflow a userspace listener's buffers. One approach to avoiding overflow is to allow listeners to get data for a limited and specific set of cpus. By sc