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: 29+ 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 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
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox