From: Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org>
To: KAMEZAWA Hiroyuki
<kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
Cc: "linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org"
<linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org>,
Ying Han <yinghan-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
"hugh.dickins-IWqWACnzNjwqdlJmJB21zg@public.gmane.org"
<hugh.dickins-IWqWACnzNjwqdlJmJB21zg@public.gmane.org>,
"hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org"
<hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
"bsingharora-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
<bsingharora-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: [RFC] [PATCH 7/7 v2] memcg: make mem_cgroup_begin_update_stat to use global pcpu.
Date: Fri, 20 Jan 2012 09:38:02 +0100 [thread overview]
Message-ID: <20120120083801.GA9655@tiehlicka.suse.cz> (raw)
In-Reply-To: <20120120111947.400b2b15.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
On Fri 20-01-12 11:19:47, KAMEZAWA Hiroyuki wrote:
> On Thu, 19 Jan 2012 15:47:12 +0100
> Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org> wrote:
>
> > On Fri 13-01-12 17:45:10, KAMEZAWA Hiroyuki wrote:
> > > From 3df71cef5757ee6547916c4952f04a263c1b8ddb Mon Sep 17 00:00:00 2001
> > > From: KAMEZAWA Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
> > > Date: Fri, 13 Jan 2012 17:07:35 +0900
> > > Subject: [PATCH 7/7] memcg: make mem_cgroup_begin_update_stat to use global pcpu.
> > >
> > > Now, a per-cpu flag to show the memcg is under account moving is
> > > now implemented as per-memcg-per-cpu.
> > >
> > > So, when accessing this, we need to access memcg 1st. But this
> > > function is called even when status update doesn't occur. Then,
> > > accessing struct memcg is an overhead in such case.
> > >
> > > This patch removes per-cpu-per-memcg MEM_CGROUP_ON_MOVE and add
> > > per-cpu vairable to do the same work. For per-memcg, atomic
> > > counter is added. By this, mem_cgroup_begin_update_stat() will
> > > just access percpu variable in usual case and don't need to find & access
> > > memcg. This reduces overhead.
> >
> > I agree that move_account is not a hotpath and that we don't have
> > to optimize for it but I guess we can do better. If we use a cookie
> > parameter for
> > mem_cgroup_{begin,end}_update_stat(struct page *page, unsigned long *cookie)
> > then we can stab page_cgroup inside and use the last bit for
> > locked. Then we do not have to call lookup_page_cgroup again in
> > mem_cgroup_update_page_stat and just replace page by the cookie.
> > What do you think?
> >
>
> Because these routine is called as
>
> mem_cgroup_begin_update_stat()
> if (condition)
> set_page_flag
> mem_cgroup_update_stat()
> mem_cgroup_end_update_stat()
>
> In earlier version(not posted), I did so. Now, I don't because of 2 reasons.
>
> 1. I wonder it's better not to have extra arguments in begin_xxx it
> will be overhead itself.
I am not sure this could be noticable.
> 2. my work's final purpose is integrate page_cgroup to struct page.
> If I can do, lookup_page_cgroup() cost will be almost 0 and we'll revert
> the cookie, finally.
OK
> So, can't we keep this update routine simple for a while ?
Sure. I was just concerned that global move account state might be an
issue because we would have an side effect interaction between different
cgroups.
> If we saw it's finally impossible to integrate page_cgroup to page,
> I'd like to consider 'cookie' again.
>
> BTW, If we use spinlock and need to do irq_disable() in begin_update_stat()
> we'll need to pass *flags...
Right, you said that dirty page accounting requires to be called from
IRQ context as well.
>
> Thanks,
> -Kame
>
> --
> To unsubscribe from this list: send the line "unsubscribe cgroups" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9
Czech Republic
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@suse.cz>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
Ying Han <yinghan@google.com>,
"hugh.dickins@tiscali.co.uk" <hugh.dickins@tiscali.co.uk>,
"hannes@cmpxchg.org" <hannes@cmpxchg.org>,
cgroups@vger.kernel.org,
"bsingharora@gmail.com" <bsingharora@gmail.com>
Subject: Re: [RFC] [PATCH 7/7 v2] memcg: make mem_cgroup_begin_update_stat to use global pcpu.
Date: Fri, 20 Jan 2012 09:38:02 +0100 [thread overview]
Message-ID: <20120120083801.GA9655@tiehlicka.suse.cz> (raw)
In-Reply-To: <20120120111947.400b2b15.kamezawa.hiroyu@jp.fujitsu.com>
On Fri 20-01-12 11:19:47, KAMEZAWA Hiroyuki wrote:
> On Thu, 19 Jan 2012 15:47:12 +0100
> Michal Hocko <mhocko@suse.cz> wrote:
>
> > On Fri 13-01-12 17:45:10, KAMEZAWA Hiroyuki wrote:
> > > From 3df71cef5757ee6547916c4952f04a263c1b8ddb Mon Sep 17 00:00:00 2001
> > > From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> > > Date: Fri, 13 Jan 2012 17:07:35 +0900
> > > Subject: [PATCH 7/7] memcg: make mem_cgroup_begin_update_stat to use global pcpu.
> > >
> > > Now, a per-cpu flag to show the memcg is under account moving is
> > > now implemented as per-memcg-per-cpu.
> > >
> > > So, when accessing this, we need to access memcg 1st. But this
> > > function is called even when status update doesn't occur. Then,
> > > accessing struct memcg is an overhead in such case.
> > >
> > > This patch removes per-cpu-per-memcg MEM_CGROUP_ON_MOVE and add
> > > per-cpu vairable to do the same work. For per-memcg, atomic
> > > counter is added. By this, mem_cgroup_begin_update_stat() will
> > > just access percpu variable in usual case and don't need to find & access
> > > memcg. This reduces overhead.
> >
> > I agree that move_account is not a hotpath and that we don't have
> > to optimize for it but I guess we can do better. If we use a cookie
> > parameter for
> > mem_cgroup_{begin,end}_update_stat(struct page *page, unsigned long *cookie)
> > then we can stab page_cgroup inside and use the last bit for
> > locked. Then we do not have to call lookup_page_cgroup again in
> > mem_cgroup_update_page_stat and just replace page by the cookie.
> > What do you think?
> >
>
> Because these routine is called as
>
> mem_cgroup_begin_update_stat()
> if (condition)
> set_page_flag
> mem_cgroup_update_stat()
> mem_cgroup_end_update_stat()
>
> In earlier version(not posted), I did so. Now, I don't because of 2 reasons.
>
> 1. I wonder it's better not to have extra arguments in begin_xxx it
> will be overhead itself.
I am not sure this could be noticable.
> 2. my work's final purpose is integrate page_cgroup to struct page.
> If I can do, lookup_page_cgroup() cost will be almost 0 and we'll revert
> the cookie, finally.
OK
> So, can't we keep this update routine simple for a while ?
Sure. I was just concerned that global move account state might be an
issue because we would have an side effect interaction between different
cgroups.
> If we saw it's finally impossible to integrate page_cgroup to page,
> I'd like to consider 'cookie' again.
>
> BTW, If we use spinlock and need to do irq_disable() in begin_update_stat()
> we'll need to pass *flags...
Right, you said that dirty page accounting requires to be called from
IRQ context as well.
>
> Thanks,
> -Kame
>
> --
> To unsubscribe from this list: send the line "unsubscribe cgroups" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9
Czech Republic
--
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-01-20 8:38 UTC|newest]
Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-13 8:30 [RFC] [PATCH 0/7 v2] memcg: page_cgroup diet KAMEZAWA Hiroyuki
2012-01-13 8:32 ` [RFC] [PATCH 1/7 v2] memcg: remove unnecessary check in mem_cgroup_update_page_stat() KAMEZAWA Hiroyuki
2012-01-13 8:32 ` KAMEZAWA Hiroyuki
[not found] ` <20120113173227.df2baae3.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2012-01-17 15:16 ` Michal Hocko
2012-01-17 15:16 ` Michal Hocko
[not found] ` <20120117151619.GA21348-VqjxzfR4DlwKmadIfiO5sKVXKuFTiq87@public.gmane.org>
2012-01-17 23:55 ` KAMEZAWA Hiroyuki
2012-01-17 23:55 ` KAMEZAWA Hiroyuki
[not found] ` <20120118085558.6ed1a988.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2012-01-18 13:01 ` Michal Hocko
2012-01-18 13:01 ` Michal Hocko
[not found] ` <20120118130102.GC31112-VqjxzfR4DlwKmadIfiO5sKVXKuFTiq87@public.gmane.org>
2012-01-19 2:18 ` KAMEZAWA Hiroyuki
2012-01-19 2:18 ` KAMEZAWA Hiroyuki
2012-01-19 20:07 ` Ying Han
2012-01-19 20:07 ` Ying Han
2012-01-20 0:48 ` KAMEZAWA Hiroyuki
2012-01-20 0:48 ` KAMEZAWA Hiroyuki
[not found] ` <20120113173001.ee5260ca.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2012-01-13 8:33 ` [RFC] [PATCH 2/7 v2] memcg: add memory barrier for checking account move KAMEZAWA Hiroyuki
2012-01-13 8:33 ` KAMEZAWA Hiroyuki
[not found] ` <20120113173347.6231f510.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2012-01-17 15:26 ` Michal Hocko
2012-01-17 15:26 ` Michal Hocko
[not found] ` <20120117152635.GA22142-VqjxzfR4DlwKmadIfiO5sKVXKuFTiq87@public.gmane.org>
2012-01-18 0:06 ` KAMEZAWA Hiroyuki
2012-01-18 0:06 ` KAMEZAWA Hiroyuki
2012-01-18 12:37 ` Michal Hocko
[not found] ` <20120118123759.GB31112-VqjxzfR4DlwKmadIfiO5sKVXKuFTiq87@public.gmane.org>
2012-01-19 2:17 ` KAMEZAWA Hiroyuki
2012-01-19 2:17 ` KAMEZAWA Hiroyuki
2012-01-19 9:28 ` Michal Hocko
[not found] ` <20120119092833.GA13932-VqjxzfR4DlwKmadIfiO5sKVXKuFTiq87@public.gmane.org>
2012-01-19 23:57 ` KAMEZAWA Hiroyuki
2012-01-19 23:57 ` KAMEZAWA Hiroyuki
[not found] ` <20120119111727.6337bde4.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2012-01-20 18:08 ` Ying Han
2012-01-20 18:08 ` Ying Han
[not found] ` <CALWz4iz59=-J+cif+XickXBG3zUSy58yHhkX6j3zbJyBXGzpYw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-01-23 9:04 ` Michal Hocko
2012-01-23 9:04 ` Michal Hocko
[not found] ` <20120123090436.GA12375-VqjxzfR4DlwKmadIfiO5sKVXKuFTiq87@public.gmane.org>
2012-01-24 3:21 ` KAMEZAWA Hiroyuki
2012-01-24 3:21 ` KAMEZAWA Hiroyuki
2012-01-24 8:49 ` Michal Hocko
2012-01-24 8:49 ` Michal Hocko
2012-01-24 19:04 ` Ying Han
2012-01-24 19:04 ` Ying Han
[not found] ` <CALWz4iyaWtes=aU79DAbEfBsNUTaHKLK5HZbNfShaxgC8UX_TQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-01-25 11:07 ` Michal Hocko
2012-01-25 11:07 ` Michal Hocko
2012-01-13 8:40 ` [RFC] [PATCH 3/7 v2] memcg: remove PCG_MOVE_LOCK flag from pc->flags KAMEZAWA Hiroyuki
2012-01-13 8:40 ` KAMEZAWA Hiroyuki
2012-01-16 12:55 ` Kirill A. Shutemov
[not found] ` <20120116125526.GB25981-oKw7cIdHH8eLwutG50LtGA@public.gmane.org>
2012-01-17 0:22 ` KAMEZAWA Hiroyuki
2012-01-17 0:22 ` KAMEZAWA Hiroyuki
[not found] ` <20120113174019.8dff3fc1.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2012-01-17 16:46 ` Michal Hocko
2012-01-17 16:46 ` Michal Hocko
2012-01-18 0:12 ` KAMEZAWA Hiroyuki
2012-01-18 10:47 ` Michal Hocko
[not found] ` <20120118104703.GA31112-VqjxzfR4DlwKmadIfiO5sKVXKuFTiq87@public.gmane.org>
2012-01-18 23:53 ` KAMEZAWA Hiroyuki
2012-01-18 23:53 ` KAMEZAWA Hiroyuki
[not found] ` <20120119085309.616cadb4.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2012-01-23 22:05 ` Ying Han
2012-01-23 22:05 ` Ying Han
2012-01-24 4:59 ` KAMEZAWA Hiroyuki
2012-01-24 4:59 ` KAMEZAWA Hiroyuki
[not found] ` <CALWz4ixAT411PZMwngh17V8VZEDGbMNNzbWFwbpC5M-JO+TVOQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-01-24 8:43 ` Michal Hocko
2012-01-24 8:43 ` Michal Hocko
[not found] ` <20120124084335.GE26289-VqjxzfR4DlwKmadIfiO5sKVXKuFTiq87@public.gmane.org>
2012-01-25 23:07 ` Ying Han
2012-01-25 23:07 ` Ying Han
[not found] ` <CALWz4iy0ajriTk7V0xL1+W7rDFS+-M5w4OdPjasMGUTH=ZLgrw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-01-26 9:16 ` Michal Hocko
2012-01-26 9:16 ` Michal Hocko
2012-01-23 22:02 ` Ying Han
[not found] ` <CALWz4izasaECifCYoRXL45x1YXYzACC=kUHQivnGZKRH+ySjuw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-01-24 4:47 ` KAMEZAWA Hiroyuki
2012-01-24 4:47 ` KAMEZAWA Hiroyuki
2012-01-25 22:48 ` Ying Han
2012-01-13 8:42 ` [RFC] [PATCH 5/7 v2] memcg: remove PCG_FILE_MAPPED KAMEZAWA Hiroyuki
2012-01-13 8:42 ` KAMEZAWA Hiroyuki
[not found] ` <20120113174223.aaf5a80c.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2012-01-19 14:07 ` Michal Hocko
2012-01-19 14:07 ` Michal Hocko
[not found] ` <20120119140737.GD13932-VqjxzfR4DlwKmadIfiO5sKVXKuFTiq87@public.gmane.org>
2012-01-26 19:10 ` Ying Han
2012-01-26 19:10 ` Ying Han
2012-01-13 8:43 ` [RFC] [PATCH 6/7 v2] memcg: remove PCG_CACHE KAMEZAWA Hiroyuki
2012-01-13 8:43 ` KAMEZAWA Hiroyuki
2012-01-13 8:41 ` [RFC] [PATCH 4/7 v2] memcg: new scheme to update per-memcg page stat accounting KAMEZAWA Hiroyuki
2012-01-13 8:41 ` KAMEZAWA Hiroyuki
2012-01-18 16:45 ` Michal Hocko
2012-01-18 23:58 ` KAMEZAWA Hiroyuki
[not found] ` <20120113174138.ec7b64d9.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2012-01-26 19:01 ` Ying Han
2012-01-26 19:01 ` Ying Han
2012-01-13 8:45 ` [RFC] [PATCH 7/7 v2] memcg: make mem_cgroup_begin_update_stat to use global pcpu KAMEZAWA Hiroyuki
2012-01-13 8:45 ` KAMEZAWA Hiroyuki
2012-01-19 14:47 ` Michal Hocko
[not found] ` <20120119144712.GG13932-VqjxzfR4DlwKmadIfiO5sKVXKuFTiq87@public.gmane.org>
2012-01-20 2:19 ` KAMEZAWA Hiroyuki
2012-01-20 2:19 ` KAMEZAWA Hiroyuki
[not found] ` <20120120111947.400b2b15.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2012-01-20 8:38 ` Michal Hocko [this message]
2012-01-20 8:38 ` Michal Hocko
2012-01-20 8:40 ` Greg Thelen
[not found] ` <CAHH2K0ZzE55Dx=pz+cR1US3UnUbUxuyVjM=N3kf3NN+Rz8GJjQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-01-24 3:18 ` KAMEZAWA Hiroyuki
2012-01-24 3:18 ` 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=20120120083801.GA9655@tiehlicka.suse.cz \
--to=mhocko-alswssmvlrq@public.gmane.org \
--cc=bsingharora-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
--cc=hugh.dickins-IWqWACnzNjwqdlJmJB21zg@public.gmane.org \
--cc=kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org \
--cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
--cc=yinghan-hpIqsD4AKlfQT0dZR+AlfA@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.