From: Bharata B Rao <bharata.rao@gmail.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
paulmck@linux.vnet.ibm.com, Li Zefan <lizf@cn.fujitsu.com>,
Ingo Molnar <mingo@elte.hu>, Paul Menage <menage@google.com>,
Balbir Singh <balbir@linux.vnet.ibm.com>,
kenchen@google.com
Subject: Re: [PATCH] remove rq->lock from cpuacct cgroup v2
Date: Wed, 4 Mar 2009 17:41:13 +0530 [thread overview]
Message-ID: <344eb09a0903040411n12379babjb62d31d28b77d1e6@mail.gmail.com> (raw)
In-Reply-To: <20090304172005.99f5b0a2.kamezawa.hiroyu@jp.fujitsu.com>
On Wed, Mar 4, 2009 at 1:50 PM, KAMEZAWA Hiroyuki
<kamezawa.hiroyu@jp.fujitsu.com> wrote:
> On Wed, 4 Mar 2009 13:24:43 +0530
> Bharata B Rao <bharata.rao@gmail.com> wrote:
>
>> Instead of subsystems handling all these percpu counter problems
>> themselves, shouldn't we be using percpu_counter subsytem and let it
>> handle all the issues transparently for us ? I am not sure if all
>> these problems have been addressed in percpu_counter, but would like
>> to know why we are not using percpu_counter for these kinds of things
>> and enhance percpu_counter if it can't handle some of the issues which
>> we are solving here specifically for cpuacct subsystem ?
>>
> At first, generic per-cpu counter sounds interesting but to be honest,
> some special handling is used for cpuacct based on its characteristic.
>
Just trying to understand this clearly ...
> - Writer works under non-preemptable context.
Which means the writer is running with preemption disabled.
percpu_counter writes (via percpu_counter_add) don't assume anything
and disable preemption themselves. Is this the problem or is there a
bigger issue here why percpu_counter can't be used ?
> - There is only one writer.
Not sure how you have optimized for this case in cpuacct.
percpu_counters use spinlocks to serialize writers. Are you saying
using spinlocks for this 1 writer case is too much ? Also note that
they update 32 bit percpu counters without any lock and take spinlocks
only when they do a batch update to the 64bit counter.
Regards,
Bharata.
--
http://bharata.sulekha.com/blog/posts.htm
next prev parent reply other threads:[~2009-03-04 12:11 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-26 7:40 [PATCH] cpuacct: add a branch prediction Li Zefan
2009-02-26 8:07 ` KAMEZAWA Hiroyuki
2009-02-26 8:17 ` Li Zefan
2009-02-26 8:22 ` KAMEZAWA Hiroyuki
2009-02-26 8:35 ` Li Zefan
2009-02-26 8:40 ` KAMEZAWA Hiroyuki
2009-02-26 10:10 ` Bharata B Rao
2009-02-26 10:28 ` KAMEZAWA Hiroyuki
2009-02-26 10:44 ` Peter Zijlstra
2009-02-26 10:55 ` KAMEZAWA Hiroyuki
2009-02-26 11:22 ` Peter Zijlstra
2009-02-26 11:17 ` KAMEZAWA Hiroyuki
2009-02-26 11:28 ` Peter Zijlstra
2009-02-26 12:06 ` KAMEZAWA Hiroyuki
2009-02-26 12:20 ` Peter Zijlstra
2009-02-26 12:26 ` Ingo Molnar
2009-02-26 12:40 ` Arnd Bergmann
2009-02-27 4:25 ` Paul Mackerras
2009-02-26 16:45 ` Paul E. McKenney
2009-02-27 0:58 ` KAMEZAWA Hiroyuki
2009-02-27 1:29 ` Paul E. McKenney
2009-02-27 3:22 ` [RFC][PATCH] remove rq->lock from cpuacct cgroup (Was " KAMEZAWA Hiroyuki
2009-03-02 14:56 ` Peter Zijlstra
2009-03-02 23:42 ` KAMEZAWA Hiroyuki
2009-03-03 7:51 ` Peter Zijlstra
2009-03-03 9:04 ` KAMEZAWA Hiroyuki
2009-03-03 9:40 ` Peter Zijlstra
2009-03-03 10:42 ` KAMEZAWA Hiroyuki
2009-03-03 10:44 ` KAMEZAWA Hiroyuki
2009-03-03 11:54 ` Peter Zijlstra
2009-03-04 6:32 ` [PATCH] remove rq->lock from cpuacct cgroup v2 KAMEZAWA Hiroyuki
2009-03-04 7:54 ` Bharata B Rao
2009-03-04 8:20 ` KAMEZAWA Hiroyuki
2009-03-04 8:46 ` KAMEZAWA Hiroyuki
2009-03-04 10:35 ` Bharata B Rao
2009-03-04 12:11 ` Bharata B Rao [this message]
2009-03-04 14:17 ` KAMEZAWA Hiroyuki
2009-02-26 8:37 ` [PATCH] cpuacct: add a branch prediction Balbir Singh
2009-02-26 8:41 ` Li Zefan
2009-02-26 10:40 ` Balbir Singh
2009-02-26 10:43 ` Peter Zijlstra
2009-02-26 8:43 ` KAMEZAWA Hiroyuki
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=344eb09a0903040411n12379babjb62d31d28b77d1e6@mail.gmail.com \
--to=bharata.rao@gmail.com \
--cc=a.p.zijlstra@chello.nl \
--cc=balbir@linux.vnet.ibm.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kenchen@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=menage@google.com \
--cc=mingo@elte.hu \
--cc=paulmck@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
all inboxes | Powered by JetHome®