From: Andrew Morton <akpm@osdl.org>
To: Shailabh Nagar <nagar@watson.ibm.com>
Cc: jlan@sgi.com, pj@sgi.com, Valdis.Kletnieks@vt.edu,
balbir@in.ibm.com, csturtiv@sgi.com,
linux-kernel@vger.kernel.org, hadi@cyberus.ca,
netdev@vger.kernel.org
Subject: Re: [PATCH] per-task delay accounting taskstats interface: control exit data through cpumasks]
Date: Thu, 6 Jul 2006 02:56:33 -0700 [thread overview]
Message-ID: <20060706025633.cd4b1c1d.akpm@osdl.org> (raw)
In-Reply-To: <44ACD7C3.5040008@watson.ibm.com>
On Thu, 06 Jul 2006 05:28:35 -0400
Shailabh Nagar <nagar@watson.ibm.com> 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 overflow is to allow listeners to get data for
> a limited and specific set of cpus. By scaling the number of listeners
> and/or the cpus they monitor, userspace can handle the statistical data
> overload more gracefully.
>
> In this patch, each listener registers to listen to a specific set of
> cpus by specifying a cpumask. The interest is recorded per-cpu. When
> a task exits on a cpu, its taskstats data is unicast to each listener
> interested in that cpu.
>
> Thanks to Andrew Morton for pointing out the various scalability and
> general concerns of previous attempts and for suggesting this design.
>
> ...
>
> --- linux-2.6.17-mm3equiv.orig/include/linux/taskstats.h 2006-06-30 19:03:40.000000000 -0400
> +++ linux-2.6.17-mm3equiv/include/linux/taskstats.h 2006-07-06 02:38:28.000000000 -0400
Your email client performs space-stuffing. Fortunately "sed -e 's/^ / /'"
is easy.
> #include <linux/taskstats_kern.h>
> #include <linux/delayacct.h>
> +#include <linux/cpumask.h>
> +#include <linux/percpu.h>
> #include <net/genetlink.h>
> #include <asm/atomic.h>
Like that.
>
> +static int add_del_listener(pid_t pid, cpumask_t *maskp, int isadd)
> +{
> + struct listener *s;
> + struct listener_list *listeners;
> + unsigned int cpu;
> + cpumask_t mask;
> + struct list_head *p;
> +
> + memcpy(&mask, maskp, sizeof(cpumask_t));
mask = *maskp; ?
> + if (!cpus_subset(mask, cpu_possible_map))
> + return -EINVAL;
> +
> + if (isadd == REGISTER) {
> + for_each_cpu_mask(cpu, mask) {
> + s = kmalloc_node(sizeof(struct listener), GFP_KERNEL,
> + cpu_to_node(cpu));
> + if (!s)
> + return -ENOMEM;
> + s->pid = pid;
> + INIT_LIST_HEAD(&s->list);
> +
> + listeners = &per_cpu(listener_array, cpu);
> + down_write(&listeners->sem);
> + list_add(&s->list, &listeners->list);
> + up_write(&listeners->sem);
> + }
> + } else {
> + for_each_cpu_mask(cpu, mask) {
> + struct list_head *tmp;
> +
> + listeners = &per_cpu(listener_array, cpu);
> + down_write(&listeners->sem);
> + list_for_each_safe(p, tmp, &listeners->list) {
> + s = list_entry(p, struct listener, list);
> + if (s->pid == pid) {
> + list_del(&s->list);
> + kfree(s);
> + break;
> + }
> + }
> + up_write(&listeners->sem);
> + }
> + }
> + return 0;
> +}
You might choose to handle the ENOMEM situation here by backing out and not
leaving things half-installed. I suspect that's just a simple `goto'.
> -static int taskstats_send_stats(struct sk_buff *skb, struct genl_info *info)
> +static int taskstats_user_cmd(struct sk_buff *skb, struct genl_info *info)
> {
> int rc = 0;
> struct sk_buff *rep_skb;
> @@ -210,6 +302,25 @@ static int taskstats_send_stats(struct s
> void *reply;
> size_t size;
> struct nlattr *na;
> + cpumask_t mask;
When counting add_del_listener(), that's two cpumasks on the stack. How
big can these get? 256 bytes? Is it possible to get by with just the one?
> +
> + if (info->attrs[TASKSTATS_CMD_ATTR_REGISTER_CPUMASK]) {
> + na = info->attrs[TASKSTATS_CMD_ATTR_REGISTER_CPUMASK];
> + if (nla_len(na) > TASKSTATS_CPUMASK_MAXLEN)
> + return -E2BIG;
> + cpulist_parse((char *)nla_data(na), mask);
Best check the return value from this function.
> + rc = add_del_listener(info->snd_pid, &mask, REGISTER);
> + return rc;
> + }
> +
> + if (info->attrs[TASKSTATS_CMD_ATTR_DEREGISTER_CPUMASK]) {
> + na = info->attrs[TASKSTATS_CMD_ATTR_DEREGISTER_CPUMASK];
> + if (nla_len(na) > TASKSTATS_CPUMASK_MAXLEN)
> + return -E2BIG;
> + cpulist_parse((char *)nla_data(na), mask);
> + rc = add_del_listener(info->snd_pid, &mask, DEREGISTER);
> + return rc;
> + }
>
> ...
>
> +void taskstats_exit_alloc(struct taskstats **ptidstats, unsigned int *mycpu)
> +{
> + struct listener_list *listeners;
> + struct taskstats *tmp;
> + /*
> + * This is the cpu on which the task is exiting currently and will
> + * be the one for which the exit event is sent, even if the cpu
> + * on which this function is running changes later.
> + */
> + *mycpu = raw_smp_processor_id();
> +
> + *ptidstats = NULL;
> + tmp = kmem_cache_zalloc(taskstats_cache, SLAB_KERNEL);
> + if (!tmp)
> + return;
> +
> + listeners = &per_cpu(listener_array, *mycpu);
> + down_read(&listeners->sem);
> + if (!list_empty(&listeners->list)) {
> + *ptidstats = tmp;
> + tmp = NULL;
> + }
> + up_read(&listeners->sem);
> + if (tmp)
> + kfree(tmp);
kfree(NULL) is legal.
Looks good to me. Does it work?
next prev parent reply other threads:[~2006-07-06 10:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-06 9:28 [PATCH] per-task delay accounting taskstats interface: control exit data through cpumasks] Shailabh Nagar
2006-07-06 9:56 ` Andrew Morton [this message]
2006-07-06 10:44 ` Shailabh Nagar
2006-07-06 11:37 ` Shailabh Nagar
2006-07-06 12:08 ` Thomas Graf
2006-07-06 13:21 ` Shailabh Nagar
2006-07-06 21:48 ` Andrew Morton
2006-07-06 22:27 ` Shailabh Nagar
2006-07-06 22:56 ` Andrew Morton
2006-07-07 10:21 ` Thomas Graf
2006-07-06 22:40 ` Thomas Graf
2006-07-06 23:05 ` Andrew Morton
2006-07-07 10:16 ` Thomas Graf
2006-07-07 6:18 ` Paul Jackson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060706025633.cd4b1c1d.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=Valdis.Kletnieks@vt.edu \
--cc=balbir@in.ibm.com \
--cc=csturtiv@sgi.com \
--cc=hadi@cyberus.ca \
--cc=jlan@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nagar@watson.ibm.com \
--cc=netdev@vger.kernel.org \
--cc=pj@sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).