netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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?

  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).