From: Glauber Costa <glommer@parallels.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.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 0/7] Initial proposal for faster res_counter updates
Date: Fri, 30 Mar 2012 12:46:17 +0200 [thread overview]
Message-ID: <4F758EF9.5030008@parallels.com> (raw)
In-Reply-To: <4F756F86.8030906@jp.fujitsu.com>
> Note: Assume a big system which has many cpus, and user wants to devide
> the system into containers. Current memcg's percpu caching is done
> only when a task in memcg is on the cpu, running. So, it's not so dangerous
> as it looks.
Agree. I actually think it is pretty
> But yes, if we can drop memcg's code, it's good. Then, we can remove some
> amount of codes.
>
>> But the cons:
>>
>> * percpu counters have signed quantities, so this would limit us 4G.
>> We can add a shift and then count pages instead of bytes, but we
>> are still in the 16T area here. Maybe we really need more than that.
>>
>
> ....
> struct percpu_counter {
> raw_spinlock_t lock;
> s64 count;
>
> s64 limtes us 4G ?
>
Yes, I actually explicitly mentioned that. We can go to 16T if we track
pages
instead of bytes (I considered having the res_counter initialization code to
specify a shift, so we could be generic).
But I believe that if we go this route, we'll need to either:
1) Have our own internal implementation of what percpu counters does
2) create u64 acessors that would cast that to u64 in the operations.
Since it
is a 64 bit field anyway it should be doable. But being doable
doesn't mean we
should do it....
3) Have a different percpu_counter structure, something like struct
percpu_positive_counter.
>
>> * some of the additions here may slow down the percpu_counters for
>> users that don't care about our usage. Things about min/max tracking
>> enter in this category.
>>
>
>
> I think it's not very good to increase size of percpu counter. It's already
> very big...Hm. How about
>
> struct percpu_counter_lazy {
> struct percpu_counter pcp;
> extra information
> s64 margin;
> }
> ?
Can work, but we need something that also solves the signedness problem.
Maybe we can use a union for that, and then stuff things in the end of a
different
structure just for the users that want it.
--
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>
prev parent reply other threads:[~2012-03-30 10:46 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
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 [this message]
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=4F758EF9.5030008@parallels.com \
--to=glommer@parallels.com \
--cc=cgroups@vger.kernel.org \
--cc=devel@openvz.org \
--cc=hannes@cmpxchg.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-mm@kvack.org \
--cc=lizefan@huawei.com \
--cc=mhocko@suse.cz \
--cc=tj@kernel.org \
--cc=xemul@parallels.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.