From: KAMEZAWA Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
To: Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
Cc: cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org,
Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>,
Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org>,
Linux MM <linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org>,
Pavel Emelyanov <xemul-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
Subject: Re: [RFC 5/7] use percpu_counters for res_counter usage
Date: Mon, 09 Apr 2012 10:48:42 +0900 [thread overview]
Message-ID: <4F823FFA.8000401@jp.fujitsu.com> (raw)
In-Reply-To: <4F75BACC.7050704-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
(2012/03/30 22:53), Glauber Costa wrote:
> On 03/30/2012 11:58 AM, KAMEZAWA Hiroyuki wrote:
>> ==
>>
>> Now, we do consume 'reserved' usage, we can avoid css_get(), an heavy atomic
>> ops. You may need to move this code as
>>
>> rcu_read_lock()
>> ....
>> res_counter_charge()
>> if (failure) {
>> css_tryget()
>> rcu_read_unlock()
>> } else {
>> rcu_read_unlock()
>> return success;
>> }
>>
>> to compare performance. This css_get() affects performance very very much.
>
> thanks for the tip.
>
> But one thing:
>
> To be sure: it effectively mean that we are drawing from a dead memcg
> (because we pre-allocated, right?
Cached stock is consumed by the current task. It blocks removal of memcg.
It's not dead.
Thanks,
-Kame
WARNING: multiple messages have this Message-ID (diff)
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: Glauber Costa <glommer@parallels.com>
Cc: cgroups@vger.kernel.org, Li Zefan <lizefan@huawei.com>,
Tejun Heo <tj@kernel.org>,
devel@openvz.org, Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@suse.cz>, Linux MM <linux-mm@kvack.org>,
Pavel Emelyanov <xemul@parallels.com>
Subject: Re: [RFC 5/7] use percpu_counters for res_counter usage
Date: Mon, 09 Apr 2012 10:48:42 +0900 [thread overview]
Message-ID: <4F823FFA.8000401@jp.fujitsu.com> (raw)
In-Reply-To: <4F75BACC.7050704@parallels.com>
(2012/03/30 22:53), Glauber Costa wrote:
> On 03/30/2012 11:58 AM, KAMEZAWA Hiroyuki wrote:
>> ==
>>
>> Now, we do consume 'reserved' usage, we can avoid css_get(), an heavy atomic
>> ops. You may need to move this code as
>>
>> rcu_read_lock()
>> ....
>> res_counter_charge()
>> if (failure) {
>> css_tryget()
>> rcu_read_unlock()
>> } else {
>> rcu_read_unlock()
>> return success;
>> }
>>
>> to compare performance. This css_get() affects performance very very much.
>
> thanks for the tip.
>
> But one thing:
>
> To be sure: it effectively mean that we are drawing from a dead memcg
> (because we pre-allocated, right?
Cached stock is consumed by the current task. It blocks removal of memcg.
It's not dead.
Thanks,
-Kame
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2012-04-09 1:48 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-30 8:04 [RFC 0/7] Initial proposal for faster res_counter updates Glauber Costa
2012-03-30 8:04 ` Glauber Costa
[not found] ` <1333094685-5507-1-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-03-30 8:04 ` [RFC 1/7] split percpu_counter_sum Glauber Costa
2012-03-30 8:04 ` Glauber Costa
2012-03-30 8:04 ` [RFC 2/7] consolidate all res_counter manipulation Glauber Costa
2012-03-30 8:04 ` Glauber Costa
2012-03-30 8:04 ` [RFC 3/7] bundle a percpu counter into res_counters and use its lock Glauber Costa
2012-03-30 8:04 ` Glauber Costa
2012-03-30 8:04 ` [RFC 4/7] move res_counter_set limit to res_counter.c Glauber Costa
2012-03-30 8:04 ` Glauber Costa
2012-03-30 8:04 ` [RFC 5/7] use percpu_counters for res_counter usage Glauber Costa
2012-03-30 8:04 ` Glauber Costa
[not found] ` <1333094685-5507-6-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-03-30 9:33 ` KAMEZAWA Hiroyuki
2012-03-30 9:33 ` KAMEZAWA Hiroyuki
2012-03-30 9:58 ` KAMEZAWA Hiroyuki
2012-03-30 13:53 ` Glauber Costa
[not found] ` <4F75BACC.7050704-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-04-09 1:48 ` KAMEZAWA Hiroyuki [this message]
2012-04-09 1:48 ` KAMEZAWA Hiroyuki
[not found] ` <4F757DEB.4030006-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2012-03-30 12:59 ` Glauber Costa
2012-03-30 12:59 ` Glauber Costa
2012-03-30 8:04 ` [RFC 6/7] Add min and max statistics to percpu_counter Glauber Costa
2012-03-30 8:04 ` Glauber Costa
2012-03-30 8:04 ` [RFC 7/7] Global optimization Glauber Costa
2012-03-30 8:04 ` Glauber Costa
2012-03-30 8:32 ` [RFC 0/7] Initial proposal for faster res_counter updates KAMEZAWA Hiroyuki
2012-03-30 10:46 ` Glauber Costa
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=4F823FFA.8000401@jp.fujitsu.com \
--to=kamezawa.hiroyu-+cum20s59erqfuhtdcdx3a@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org \
--cc=glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org \
--cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
--cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
--cc=lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \
--cc=mhocko-AlSwsSmVLrQ@public.gmane.org \
--cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=xemul-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org \
/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.