From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
"balbir@linux.vnet.ibm.com" <balbir@linux.vnet.ibm.com>,
"xemul@openvz.org" <xemul@openvz.org>,
"hugh@veritas.com" <hugh@veritas.com>,
"yamamoto@valinux.co.jp" <yamamoto@valinux.co.jp>
Subject: [RFC][PATCH 7/8] memcg: remove redundant checks
Date: Mon, 28 Apr 2008 20:31:34 +0900 [thread overview]
Message-ID: <20080428203134.d7de02cc.kamezawa.hiroyu@jp.fujitsu.com> (raw)
In-Reply-To: <20080428201900.ae25e086.kamezawa.hiroyu@jp.fujitsu.com>
This patch needs review ;)
Because of remove refcnt patch, it's very rare case to that
mem_cgroup_charge_common() is called against a page which is accounted.
mem_cgroup_charge_common() is called when.
1. a page is added into file cache.
2. an anon page is newly mapped.
3. a file-cache page is newly mapped.
To rise a racy condition, above action against a page should occur
at once.
And, for case 3, we don't account it because it's already file cache.
For avoiding accounting "File cache but not mapped" page, checking
page->mapping is better than checking page_mapped().
Signed-off-by : KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
---
mm/memcontrol.c | 39 ++++++++++-----------------------------
1 file changed, 10 insertions(+), 29 deletions(-)
Index: mm-2.6.25-mm1/mm/memcontrol.c
===================================================================
--- mm-2.6.25-mm1.orig/mm/memcontrol.c
+++ mm-2.6.25-mm1/mm/memcontrol.c
@@ -527,28 +527,6 @@ static int mem_cgroup_charge_common(stru
if (mem_cgroup_subsys.disabled)
return 0;
- /*
- * Should page_cgroup's go to their own slab?
- * One could optimize the performance of the charging routine
- * by saving a bit in the page_flags and using it as a lock
- * to see if the cgroup page already has a page_cgroup associated
- * with it
- */
-retry:
- lock_page_cgroup(page);
- pc = page_get_page_cgroup(page);
- /*
- * The page_cgroup exists and
- * the page has already been accounted.
- */
- if (unlikely(pc)) {
- VM_BUG_ON(pc->page != page);
- VM_BUG_ON(!pc->mem_cgroup);
- unlock_page_cgroup(page);
- goto done;
- }
- unlock_page_cgroup(page);
-
pc = kmem_cache_alloc(page_cgroup_cache, gfp_mask);
if (unlikely(!pc))
goto err;
@@ -604,15 +582,10 @@ retry:
lock_page_cgroup(page);
if (unlikely(page_get_page_cgroup(page))) {
unlock_page_cgroup(page);
- /*
- * Another charge has been added to this page already.
- * We take lock_page_cgroup(page) again and read
- * page->cgroup, increment refcnt.... just retry is OK.
- */
res_counter_uncharge(&mem->res, PAGE_SIZE);
css_put(&mem->css);
kmem_cache_free(page_cgroup_cache, pc);
- goto retry;
+ goto done;
}
page_assign_page_cgroup(page, pc);
@@ -633,7 +606,15 @@ err:
int mem_cgroup_charge(struct page *page, struct mm_struct *mm, gfp_t gfp_mask)
{
- if (page_mapped(page))
+ /*
+ * If a page is file cache, it's already charged. If a page is anon
+ * and mapped, it's already charged. We accounts only *new* anon
+ * page here. We cannot use !PageAnon() here because a new page for
+ * anon is not marked as an anon page. we just checks a page has some
+ * objrmap context or not.
+ * Note that swap-cache's page->mapping is NULL. So we have no problem.
+ */
+ if (page->mapping)
return 0;
if (unlikely(!mm))
mm = &init_mm;
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2008-04-28 11:31 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-28 11:19 [RFC][PATCH] memcg: performance improvement v2 [0/8] KAMEZAWA Hiroyuki
2008-04-28 11:22 ` [RFC][PATCH 1/8] memcg: migration handling KAMEZAWA Hiroyuki
2008-04-29 1:36 ` Li Zefan
2008-04-29 1:48 ` KAMEZAWA Hiroyuki
2008-04-28 11:23 ` [RFC][PATCH 2/8] memcg: remove refcnt KAMEZAWA Hiroyuki
2008-04-28 11:24 ` [RFC][PATCH 3/8] memcg: swapcache handling retry KAMEZAWA Hiroyuki
2008-04-28 11:26 ` [RFC][PATCH 4/8] memcg: read_mostly KAMEZAWA Hiroyuki
2008-04-29 1:34 ` Li Zefan
2008-04-29 1:43 ` KAMEZAWA Hiroyuki
2008-04-28 11:28 ` [RFC][PATCH 5/8] memcg: optimize branches KAMEZAWA Hiroyuki
2008-04-29 2:04 ` Li Zefan
2008-04-29 2:48 ` KAMEZAWA Hiroyuki
2008-04-29 3:11 ` KAMEZAWA Hiroyuki
2008-04-28 11:30 ` [RFC][PATCH 6/8] memcg: remove redundant initilization KAMEZAWA Hiroyuki
2008-04-28 11:31 ` KAMEZAWA Hiroyuki [this message]
2008-04-28 11:32 ` [RFC][PATCH 8/8] memcg: inlining mem_cgroup_chage_statistics() 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=20080428203134.d7de02cc.kamezawa.hiroyu@jp.fujitsu.com \
--to=kamezawa.hiroyu@jp.fujitsu.com \
--cc=balbir@linux.vnet.ibm.com \
--cc=hugh@veritas.com \
--cc=linux-mm@kvack.org \
--cc=xemul@openvz.org \
--cc=yamamoto@valinux.co.jp \
/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