From: Bharata B Rao <bharata@linux.vnet.ibm.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: linux-kernel@vger.kernel.org, Balaji Rao <balajirrao@gmail.com>,
Dhaval Giani <dhaval@linux.vnet.ibm.com>,
Balbir Singh <balbir@linux.vnet.ibm.com>,
Li Zefan <lizf@cn.fujitsu.com>, Paul Menage <menage@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Ingo Molnar <mingo@elte.hu>,
Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [PATCH -tip] cpuacct: per-cgroup utime/stime statistics - v4
Date: Mon, 23 Mar 2009 12:06:03 +0530 [thread overview]
Message-ID: <20090323063603.GA15360@in.ibm.com> (raw)
In-Reply-To: <20090323135528.ddf795f6.kamezawa.hiroyu@jp.fujitsu.com>
On Mon, Mar 23, 2009 at 01:55:28PM +0900, KAMEZAWA Hiroyuki wrote:
> On Mon, 23 Mar 2009 10:05:38 +0530
> Bharata B Rao <bharata@linux.vnet.ibm.com> wrote:
>
> > Hi Ingo,
> >
> > Here is the v4 of the cpuacct statistics patch to obtain per-cgroup
> > system and user times with appropriate tags and complete changelog.
> > This applies against the latest -tip plus the cpuacct hierarchy fix v2
> > which I posted just now. Could you please include this in -tip ?
> >
> > Changelog:
> >
> > v4
> > - Remove comments in cpuacct_update_stats() which explained why rcu_read_lock()
> > was needed (as per Peter Zijlstra's review comments).
> > - Don't say that percpu_counter_read() is broken in Documentation/cpuacct.txt
> > as per KAMEZAWA Hiroyuki's review comments.
> >
> Broken -> isn't safe ? no difference ;)
>From your comment last time, I thought you meant calling it broken would
be harsh.
> Can't this help you ?
>
>
> Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> ---
> Index: mmotm-2.6.29-Mar21/include/linux/percpu_counter.h
> ===================================================================
> --- mmotm-2.6.29-Mar21.orig/include/linux/percpu_counter.h
> +++ mmotm-2.6.29-Mar21/include/linux/percpu_counter.h
> @@ -62,6 +62,16 @@ static inline s64 percpu_counter_read(st
> return fbc->count;
> }
>
> +static inline s64 percpu_counter_read_safe(struct percpu_counter *fbc)
> +{
> + s64 ret;
> +
> + spin_lock(&fbc->lock);
> + ret = fbc->count;
> + spin_unlock(&fbc->lock);
> + return ret;
> +}
> +
> /*
> * It is possible for the percpu_counter_read() to return a small negative
> * number for some counter which should never be negative.
> @@ -114,6 +124,11 @@ static inline s64 percpu_counter_read(st
> return fbc->count;
> }
>
> +static inline s64 percpu_counter_read_safe(struct percpu_counter *fbc)
> +{
> + return fbc->count;
> +}
> +
> static inline s64 percpu_counter_read_positive(struct percpu_counter *fbc)
> {
> return fbc->count;
Yes it helps, but for the records, let me note that it makes the readside
~20% slower.
[I measured time spent by cpuacct_stats_show(), which is part of
the read routine for cpuacct.stat by using kretprobe and for 100 reads
(or 100 executions of cpuacct_stats_show()), I get the following numbers:
percpu_counter_read() - 3166367 ns
percpu_counter_read_safe() - 3793546 ns which is ~20% slower. ]
I would prefer that this patch should be included in its current form
and we could separately fix percpu_counter_read() given that there
has been an attempt in the past to fix this (http://lkml.org/lkml/2008/8/27/303)
Moreover, I don't know how much acceptable it is to work around the problem
in percpu_counter_read() by introducing another variant
percpu_counter_read_safe().
Regards,
Bharata.
next prev parent reply other threads:[~2009-03-23 6:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-23 4:35 [PATCH -tip] cpuacct: per-cgroup utime/stime statistics - v4 Bharata B Rao
2009-03-23 4:55 ` KAMEZAWA Hiroyuki
2009-03-23 6:36 ` Bharata B Rao [this message]
2009-03-23 7:01 ` KAMEZAWA Hiroyuki
2009-03-23 7:47 ` Bharata B Rao
2009-03-23 7:48 ` KAMEZAWA Hiroyuki
2009-03-23 11:21 ` Andrew Morton
2009-03-23 16:21 ` Bharata B Rao
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=20090323063603.GA15360@in.ibm.com \
--to=bharata@linux.vnet.ibm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=balajirrao@gmail.com \
--cc=balbir@linux.vnet.ibm.com \
--cc=dhaval@linux.vnet.ibm.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=menage@google.com \
--cc=mingo@elte.hu \
/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.