From: Shailabh Nagar <nagar@watson.ibm.com>
To: Andrew Morton <akpm@osdl.org>
Cc: pj@sgi.com, Valdis.Kletnieks@vt.edu, jlan@engr.sgi.com,
balbir@in.ibm.com, csturtiv@sgi.com,
linux-kernel@vger.kernel.org, hadi@cyberus.ca,
netdev@vger.kernel.org
Subject: Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats
Date: Mon, 03 Jul 2006 20:13:36 -0400 [thread overview]
Message-ID: <44A9B2B0.3000205@watson.ibm.com> (raw)
In-Reply-To: <20060703144106.cc5bd6f6.akpm@osdl.org>
Andrew Morton wrote:
>On Mon, 03 Jul 2006 17:11:59 -0400
>Shailabh Nagar <nagar@watson.ibm.com> wrote:
>
>
>>
>> static inline void taskstats_exit_alloc(struct taskstats **ptidstats)
>> {
>> *ptidstats = NULL;
>>- if (taskstats_has_listeners())
>>+ if (!list_empty(&get_cpu_var(listener_list)))
>> *ptidstats = kmem_cache_zalloc(taskstats_cache, SLAB_KERNEL);
>>+ put_cpu_var(listener_list);
>> }
>>
>>
>
>It's time to uninline this function..
>
>
>
>> static inline void taskstats_exit_free(struct taskstats *tidstats)
>>Index: linux-2.6.17-mm3equiv/kernel/taskstats.c
>>===================================================================
>>--- linux-2.6.17-mm3equiv.orig/kernel/taskstats.c 2006-06-30 23:38:39.000000000 -0400
>>+++ linux-2.6.17-mm3equiv/kernel/taskstats.c 2006-07-02 00:16:18.000000000 -0400
>>@@ -19,6 +19,8 @@
>> #include <linux/kernel.h>
>> #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>
>>
>>@@ -26,6 +28,9 @@ static DEFINE_PER_CPU(__u32, taskstats_s
>> static int family_registered = 0;
>> kmem_cache_t *taskstats_cache;
>>
>>+DEFINE_PER_CPU(struct list_head, listener_list);
>>+static DEFINE_PER_CPU(struct rw_semaphore, listener_list_sem);
>>
>>
>
>Which will permit listener_list to become static - it wasn't a good name
>for a global anyway.
>
>I suggest you implement a new
>
>struct whatever {
> struct rw_semaphore sem;
> struct list_head list;
>};
>
>
Ok. The listener_list was a global to allow taskstats_exit_alloc to
access but this is better.
>static DEFINE_PER_CPU(struct whatever, listener_aray);
>
>
>
>
>> static int prepare_reply(struct genl_info *info, u8 cmd, struct sk_buff **skbp,
>> void **replyp, size_t size)
>> {
>>@@ -77,6 +92,8 @@ static int prepare_reply(struct genl_inf
>> static int send_reply(struct sk_buff *skb, pid_t pid, int event)
>> {
>> struct genlmsghdr *genlhdr = nlmsg_data((struct nlmsghdr *)skb->data);
>>+ struct rw_semaphore *sem;
>>+ struct list_head *p, *head;
>> void *reply;
>> int rc;
>>
>>@@ -88,9 +105,30 @@ static int send_reply(struct sk_buff *sk
>> return rc;
>> }
>>
>>- if (event == TASKSTATS_MSG_MULTICAST)
>>- return genlmsg_multicast(skb, pid, TASKSTATS_LISTEN_GROUP);
>>- return genlmsg_unicast(skb, pid);
>>+ if (event == TASKSTATS_MSG_UNICAST)
>>+ return genlmsg_unicast(skb, pid);
>>+
>>+ /*
>>+ * Taskstats multicast is unicasts to listeners who have registered
>>+ * interest in this cpu
>>+ */
>>+ sem = &get_cpu_var(listener_list_sem);
>>+ head = &get_cpu_var(listener_list);
>>
>>
>
>This has a double preempt_disable(), but the above will fix that.
>
>
>
>>+ down_read(sem);
>>+ list_for_each(p, head) {
>>+ int ret;
>>+ struct listener *s = list_entry(p, struct listener, list);
>>+ ret = genlmsg_unicast(skb, s->pid);
>>+ if (ret)
>>+ rc = ret;
>>+ }
>>+ up_read(sem);
>>+
>>+ put_cpu_var(listener_list);
>>+ put_cpu_var(listener_list_sem);
>>+
>>+ return rc;
>> }
>>
>> static int fill_pid(pid_t pid, struct task_struct *pidtsk,
>>@@ -201,8 +239,73 @@ ret:
>> return;
>> }
>>
>>+static int add_del_listener(pid_t pid, cpumask_t *maskp, int isadd)
>>+{
>>+ struct listener *s;
>>+ unsigned int cpu, mycpu;
>>+ cpumask_t mask;
>>+ struct rw_semaphore *sem;
>>+ struct list_head *head, *p;
>>
>>-static int taskstats_send_stats(struct sk_buff *skb, struct genl_info *info)
>>+ memcpy(&mask, maskp, sizeof(cpumask_t));
>>+ if (cpus_empty(mask))
>>+ return -EINVAL;
>>+
>>+ mycpu = get_cpu();
>>+ put_cpu();
>>
>>
>
>This is effectively raw_smp_processor_id(). And after the put_cpu(),
>`mycpu' is meaningless.
>
>
Hmm.
>
>
>>+ if (isadd == REGISTER) {
>>+ for_each_cpu_mask(cpu, mask) {
>>+ if (!cpu_possible(cpu))
>>+ continue;
>>+ if (cpu == mycpu)
>>+ preempt_disable();
>>+
>>+ sem = &per_cpu(listener_list_sem, cpu);
>>+ head = &per_cpu(listener_list, cpu);
>>+
>>+ s = kmalloc(sizeof(struct listener), GFP_KERNEL);
>>
>>
>
>Cannot do GFP_KERNEL inside preempt_disable().
>
>There's no easy solution to this problem. GFP_ATOMIC is not a good fix at
>all. One approach would be to run lock_cpu_hotplug(), then allocate (with
>GFP_KERNEL) all the memory which will be needed within the locked region,
>then take the lock, then use that preallocated memory.
>
>
>You should use kmalloc_node() here, to ensure that the memory on each CPU's
>list resides with that CPU's local memory (not _this_ CPU's local memory).
>
>
Ok.
>
>
>>+ if (!s)
>>+ return -ENOMEM;
>>+ s->pid = pid;
>>+ INIT_LIST_HEAD(&s->list);
>>+
>>+ down_write(sem);
>>+ list_add(&s->list, head);
>>+ up_write(sem);
>>+
>>+ if (cpu == mycpu)
>>+ preempt_enable();
>>
>>
>
>Actually, I don't understand the tricks which are going on with the local CPU here.
>What's it all for?
>
>
I was wanting to do a get_cpu_var for listener_list & sem
for the current cpu and per_cpu otherwise (since thats what I thought
was the recommendation
for accessing the local cpu's variable). Perhaps the preempt_disable is
uncalled for ?
>
>
>
>>+ }
>>+ } else {
>>+ for_each_cpu_mask(cpu, mask) {
>>+ struct list_head *tmp;
>>+
>>+ if (!cpu_possible(cpu))
>>+ continue;
>>
>>
>
>I guess you could just do cpus_and(mask, cpus_possible_map) on entry.
>
>
Yup !
>
>
>
>>+ if (cpu == mycpu)
>>+ preempt_disable();
>>+
>>+ sem = &per_cpu(listener_list_sem, cpu);
>>+ head = &per_cpu(listener_list, cpu);
>>+
>>+ down_write(sem);
>>+ list_for_each_safe(p, tmp, head) {
>>+ s = list_entry(p, struct listener, list);
>>+ if (s->pid == pid) {
>>+ list_del(&s->list);
>>
>>
>
>kfree(s);
>
>
Oops.
>
>
>>+ break;
>>+ }
>>+ }
>>+ up_write(sem);
>>+
>>+ if (cpu == mycpu)
>>+ preempt_enable();
>>+ }
>>+ }
>>+ return 0;
>>+}
>>+
>>+static int taskstats_user_cmd(struct sk_buff *skb, struct genl_info *info)
>> {
>> int rc = 0;
>> struct sk_buff *rep_skb;
>>@@ -210,6 +313,21 @@ static int taskstats_send_stats(struct s
>> void *reply;
>> size_t size;
>> struct nlattr *na;
>>+ cpumask_t mask;
>>+
>>+ if (info->attrs[TASKSTATS_CMD_ATTR_REGISTER_CPUMASK]) {
>>+ na = info->attrs[TASKSTATS_CMD_ATTR_REGISTER_CPUMASK];
>>+ cpulist_parse((char *)nla_data(na), mask);
>>
>>
>
>OK, so we're passing in an ASCII string. Fair enough, I think. Paul would
>know better.
>
>
next prev parent reply other threads:[~2006-07-04 0:13 UTC|newest]
Thread overview: 151+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-09 7:41 [Patch][RFC] Disabling per-tgid stats on task exit in taskstats Shailabh Nagar
2006-06-09 8:00 ` Andrew Morton
2006-06-09 10:51 ` Balbir Singh
2006-06-09 11:21 ` Andrew Morton
2006-06-09 13:20 ` Shailabh Nagar
2006-06-09 18:25 ` Jay Lan
2006-06-09 19:12 ` Shailabh Nagar
2006-06-09 15:36 ` Balbir Singh
2006-06-09 18:35 ` Jay Lan
2006-06-09 19:31 ` Shailabh Nagar
2006-06-09 21:56 ` Shailabh Nagar
2006-06-09 22:42 ` Jay Lan
2006-06-09 23:22 ` Andrew Morton
2006-06-09 23:47 ` Jay Lan
2006-06-09 23:56 ` Andrew Morton
2006-06-10 12:21 ` Shailabh Nagar
2006-06-12 18:31 ` Jay Lan
2006-06-12 21:57 ` Shailabh Nagar
2006-06-10 13:05 ` Shailabh Nagar
2006-06-12 18:54 ` Jay Lan
2006-06-21 19:11 ` Jay Lan
2006-06-21 19:14 ` Jay Lan
2006-06-21 19:34 ` Shailabh Nagar
2006-06-21 23:35 ` Jay Lan
2006-06-21 23:45 ` Shailabh Nagar
2006-06-23 17:14 ` Shailabh Nagar
2006-06-23 18:19 ` Jay Lan
2006-06-23 18:53 ` Shailabh Nagar
2006-06-23 20:00 ` Jay Lan
2006-06-23 20:16 ` Shailabh Nagar
2006-06-23 20:36 ` Jay Lan
2006-06-23 21:19 ` Andrew Morton
2006-06-23 22:07 ` Jay Lan
2006-06-23 23:47 ` Andrew Morton
2006-06-24 2:59 ` Shailabh Nagar
2006-06-24 4:39 ` Andrew Morton
2006-06-24 5:59 ` Shailabh Nagar
2006-06-26 17:33 ` Jay Lan
2006-06-26 17:52 ` Shailabh Nagar
2006-06-26 17:55 ` Andrew Morton
2006-06-26 18:00 ` Shailabh Nagar
2006-06-26 18:12 ` Andrew Morton
2006-06-26 18:26 ` Jay Lan
2006-06-26 18:39 ` Andrew Morton
2006-06-26 18:49 ` Shailabh Nagar
2006-06-26 19:00 ` Jay Lan
2006-06-28 21:30 ` Jay Lan
2006-06-28 21:53 ` Andrew Morton
2006-06-28 22:02 ` Jay Lan
2006-06-29 8:40 ` Paul Jackson
2006-06-29 12:30 ` Valdis.Kletnieks
2006-06-29 16:44 ` Paul Jackson
2006-06-29 18:01 ` Andrew Morton
2006-06-29 18:07 ` Paul Jackson
2006-06-29 18:26 ` Paul Jackson
2006-06-29 19:15 ` Shailabh Nagar
2006-06-29 19:41 ` Paul Jackson
2006-06-29 21:42 ` Shailabh Nagar
2006-06-29 21:54 ` Jay Lan
2006-06-29 22:09 ` Shailabh Nagar
2006-06-29 22:23 ` Paul Jackson
2006-06-30 0:15 ` Shailabh Nagar
2006-06-30 0:40 ` Paul Jackson
2006-06-30 1:00 ` Shailabh Nagar
2006-06-30 1:05 ` Paul Jackson
[not found] ` <44A46C6C.1090405@watson.ibm.com>
2006-06-30 0:38 ` Paul Jackson
2006-06-30 2:21 ` Paul Jackson
2006-06-30 2:46 ` Shailabh Nagar
2006-06-30 2:54 ` Paul Jackson
2006-06-30 3:02 ` Paul Jackson
2006-06-29 19:22 ` Shailabh Nagar
2006-06-29 19:10 ` Shailabh Nagar
2006-06-29 19:10 ` Shailabh Nagar
2006-06-29 19:23 ` Paul Jackson
2006-06-29 19:33 ` Andrew Morton
2006-06-29 19:43 ` Shailabh Nagar
2006-06-29 19:43 ` Shailabh Nagar
2006-06-29 20:00 ` Andrew Morton
2006-06-29 22:13 ` Shailabh Nagar
2006-06-29 22:13 ` Shailabh Nagar
2006-06-29 23:00 ` jamal
2006-06-29 20:01 ` Shailabh Nagar
2006-06-29 20:01 ` Shailabh Nagar
2006-06-29 21:22 ` Paul Jackson
2006-06-29 22:54 ` jamal
2006-06-30 0:38 ` Shailabh Nagar
2006-06-30 0:38 ` Shailabh Nagar
2006-06-30 1:05 ` Andrew Morton
2006-06-30 1:11 ` Shailabh Nagar
2006-06-30 1:11 ` Shailabh Nagar
2006-06-30 1:30 ` jamal
2006-06-30 3:01 ` Shailabh Nagar
2006-06-30 3:01 ` Shailabh Nagar
2006-06-30 12:45 ` jamal
2006-06-30 2:25 ` Paul Jackson
2006-06-30 2:35 ` Andrew Morton
2006-06-30 2:43 ` Paul Jackson
2006-06-29 19:33 ` Jay Lan
2006-06-30 18:53 ` Shailabh Nagar
2006-06-30 18:53 ` Shailabh Nagar
2006-06-30 19:10 ` Shailabh Nagar
2006-06-30 19:10 ` Shailabh Nagar
2006-06-30 19:19 ` Shailabh Nagar
2006-06-30 19:19 ` Shailabh Nagar
2006-06-30 20:19 ` jamal
2006-06-30 22:50 ` Andrew Morton
2006-07-01 2:20 ` Shailabh Nagar
2006-07-01 2:20 ` Shailabh Nagar
2006-07-01 2:43 ` Andrew Morton
2006-07-01 3:37 ` Shailabh Nagar
2006-07-01 3:37 ` Shailabh Nagar
2006-07-01 3:51 ` Andrew Morton
2006-07-03 21:11 ` Shailabh Nagar
2006-07-03 21:41 ` Andrew Morton
2006-07-04 0:13 ` Shailabh Nagar [this message]
2006-07-04 0:38 ` Andrew Morton
2006-07-04 20:19 ` Paul Jackson
2006-07-04 20:22 ` Paul Jackson
2006-07-04 0:54 ` Shailabh Nagar
2006-07-04 1:01 ` Andrew Morton
2006-07-04 13:05 ` jamal
2006-07-04 15:18 ` Shailabh Nagar
2006-07-04 16:37 ` Shailabh Nagar
2006-07-04 19:24 ` jamal
2006-07-05 14:09 ` Shailabh Nagar
2006-07-05 14:09 ` Shailabh Nagar
2006-07-05 20:25 ` Chris Sturtivant
2006-07-05 20:25 ` Chris Sturtivant
2006-07-05 20:32 ` Shailabh Nagar
2006-07-05 20:32 ` Shailabh Nagar
2006-07-03 4:53 ` Paul Jackson
2006-07-03 15:02 ` Shailabh Nagar
2006-07-03 15:55 ` Paul Jackson
2006-07-03 16:31 ` Paul Jackson
2006-07-04 0:09 ` Shailabh Nagar
2006-07-04 19:59 ` Paul Jackson
2006-07-05 17:20 ` Jay Lan
2006-07-05 17:20 ` Jay Lan
2006-07-05 18:18 ` Shailabh Nagar
2006-07-05 18:18 ` Shailabh Nagar
2006-06-30 22:56 ` Andrew Morton
2006-06-29 18:05 ` Nick Piggin
2006-06-29 12:42 ` Shailabh Nagar
2006-06-24 3:08 ` Shailabh Nagar
2006-06-21 20:38 ` Andrew Morton
2006-06-21 21:31 ` Shailabh Nagar
2006-06-21 21:45 ` Jay Lan
2006-06-21 21:54 ` Andrew Morton
2006-06-21 22:19 ` Jay Lan
2006-06-21 21:59 ` Shailabh Nagar
2006-06-09 15:55 ` Chris Sturtivant
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=44A9B2B0.3000205@watson.ibm.com \
--to=nagar@watson.ibm.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=akpm@osdl.org \
--cc=balbir@in.ibm.com \
--cc=csturtiv@sgi.com \
--cc=hadi@cyberus.ca \
--cc=jlan@engr.sgi.com \
--cc=linux-kernel@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.