From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Balaji Rao <balajirrao@gmail.com>
Cc: Dhaval Giani <dhaval@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org, containers@lists.osdl.org,
menage@google.com, balbir@in.ibm.com,
Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Subject: Re: [RFC][-mm] [1/2] Simple stats for cpu resource controller
Date: Thu, 10 Apr 2008 18:25:11 +0200 [thread overview]
Message-ID: <1207844711.7074.8.camel@twins> (raw)
In-Reply-To: <200804102140.00078.balajirrao@gmail.com>
On Thu, 2008-04-10 at 21:39 +0530, Balaji Rao wrote:
> On Monday 07 April 2008 06:54:53 pm Peter Zijlstra wrote:
> > On Sun, 2008-04-06 at 02:01 +0530, Balaji Rao wrote:
> >
> > > > > +static s64 cpu_cgroup_read_stat(struct cpu_cgroup_stat *stat,
> > > > > + enum cpu_cgroup_stat_index idx)
> > > > > +{
> > > > > + int cpu;
> > > > > + s64 ret = 0;
> > > > > + unsigned long flags;
> > > >
> > > > > +
> > > > > + local_irq_save(flags);
> > > >
> > > > I am just wondering. Is local_irq_save() enough?
> > > >
> > > Hmmm.. You are right.This does not prevent concurrent updates on other
> CPUs
> > > from crossing a 32bit boundary. Am not sure how to do this in a safe way.
> I
> > > can only think of using atomic64_t now..
> > >
> > > > > + for_each_possible_cpu(cpu)
> > > > > + ret += stat->cpustat[cpu].count[idx];
> > > > > + local_irq_restore(flags);
> > > > > +
> > > > > + return ret;
> > > > > +}
> > > > > +
> >
> > So many stats to steal code from,.. but you didn't :-(
> >
> > Look at mm/vmstat.c, that is a rather complete example.
> >
> > The trick to solving the above is to use per cpu deltas instead, the
> > deltas can be machine word size and are thus always read in an atomic
> > manner (provided they are also naturally aligned).
> >
> >
> Hi Peter,
>
> This wont work for time based statistics. At nsec granularity, a word can hold
> a time value of up to ~4s.
4 seconds is plenty for a delta, most increments are in the ms range.
> I propose to solve this problem by using a lock to protect the statistics, but
> only on 32bit architectures.
>
> I'm not sure how good a solution this is, but that's the best I can think of
> ATM.
Not needed, keep per cpu word deltas and fold into a global u64 counter
while holding a lock.
next prev parent reply other threads:[~2008-04-10 16:25 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-05 18:09 [RFC][-mm] [1/2] Simple stats for cpu resource controller Balaji Rao
2008-04-05 18:56 ` Dhaval Giani
2008-04-05 19:09 ` Balaji Rao
2008-04-05 19:40 ` Dhaval Giani
2008-04-05 19:40 ` Dhaval Giani
2008-04-05 20:31 ` Balaji Rao
2008-04-05 20:59 ` Dhaval Giani
2008-04-05 21:21 ` Balaji Rao
2008-04-06 5:12 ` Balbir Singh
2008-04-07 13:24 ` Peter Zijlstra
2008-04-10 16:09 ` Balaji Rao
2008-04-10 16:25 ` Peter Zijlstra [this message]
2008-05-01 17:41 ` [RFC][-mm] Simple stats for cpu resource controller v3 Balaji Rao
2008-05-01 21:00 ` Andrew Morton
2008-05-02 19:40 ` Balaji Rao
[not found] ` <200805030110.29511.balajirrao-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2008-05-02 19:53 ` Andrew Morton
2008-05-02 19:53 ` Andrew Morton
2008-05-02 22:47 ` Balaji Rao
2008-05-02 23:04 ` Andrew Morton
[not found] ` <200805030457.54073.balajirrao@gmail.com>
[not found] ` <20080502164133.9025a02c.akpm@linux-foundation.org>
2008-05-02 23:56 ` Balaji Rao
2008-05-03 0:19 ` Andrew Morton
2008-05-11 20:18 ` [RFC][-mm] Simple stats for cpu resource controller v4 Balaji Rao
2008-05-12 2:54 ` Li Zefan
2008-05-12 5:41 ` Balaji Rao
2008-05-12 23:48 ` Andrew Morton
2008-05-13 3:30 ` Balaji Rao
-- strict thread matches above, loose matches on Subject: below --
2008-03-26 18:18 [RFC][-mm] [1/2] Simple stats for cpu resource controller Balaji Rao
2008-03-26 19:00 ` Paul Menage
2008-03-26 19:58 ` Peter Zijlstra
2008-03-28 10:02 ` Balaji Rao
2008-03-28 10:17 ` Peter Zijlstra
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=1207844711.7074.8.camel@twins \
--to=a.p.zijlstra@chello.nl \
--cc=balajirrao@gmail.com \
--cc=balbir@in.ibm.com \
--cc=containers@lists.osdl.org \
--cc=dhaval@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=menage@google.com \
--cc=vatsa@linux.vnet.ibm.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.