LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [PATCH] Move memory controller allocations to their own slabs (v3)
@ 2008-03-13 14:03 Balbir Singh
  2008-03-14  2:56 ` KAMEZAWA Hiroyuki
  0 siblings, 1 reply; 4+ messages in thread
From: Balbir Singh @ 2008-03-13 14:03 UTC (permalink / raw)
  To: Andrew Morton, Pavel Emelianov
  Cc: Hugh Dickins, Sudhir Kumar, YAMAMOTO Takashi, Paul Menage, lizf,
	linux-kernel, taka, linux-mm, David Rientjes, Balbir Singh,
	KAMEZAWA Hiroyuki



Changelog v3

1. Remove HWCACHE_ALIGN

Changelog v2

1. Remove extra slab for mem_cgroup_per_zone

Move the memory controller data structure page_cgroup to its own slab cache.
It saves space on the system, allocations are not necessarily pushed to order
of 2 and should provide performance benefits. Users who disable the memory
controller can also double check that the memory controller is not allocating
page_cgroup's.

NOTE: Hugh Dickins brought up the issue of whether we want to mark page_cgroup
as __GFP_MOVABLE or __GFP_RECLAIMABLE. I don't think there is an easy
answer at the moment. page_cgroup's are associated with user pages,
they can be reclaimed once the user page has been reclaimed, so it might
make sense to mark them as __GFP_RECLAIMABLE. For now, I am leaving the
marking to default values that the slab allocator uses.

Comments?

Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
---

 mm/memcontrol.c |   11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff -puN mm/memcontrol.c~memory-controller-move-to-own-slab mm/memcontrol.c
--- linux-2.6.25-rc5/mm/memcontrol.c~memory-controller-move-to-own-slab	2008-03-13 17:19:01.000000000 +0530
+++ linux-2.6.25-rc5-balbir/mm/memcontrol.c	2008-03-13 17:19:42.000000000 +0530
@@ -26,6 +26,7 @@
 #include <linux/backing-dev.h>
 #include <linux/bit_spinlock.h>
 #include <linux/rcupdate.h>
+#include <linux/slab.h>
 #include <linux/swap.h>
 #include <linux/spinlock.h>
 #include <linux/fs.h>
@@ -35,6 +36,7 @@
 
 struct cgroup_subsys mem_cgroup_subsys;
 static const int MEM_CGROUP_RECLAIM_RETRIES = 5;
+static struct kmem_cache *page_cgroup_cache;
 
 /*
  * Statistics for memory cgroup.
@@ -560,7 +562,7 @@ retry:
 	}
 	unlock_page_cgroup(page);
 
-	pc = kzalloc(sizeof(struct page_cgroup), gfp_mask);
+	pc = kmem_cache_zalloc(page_cgroup_cache, gfp_mask);
 	if (pc == NULL)
 		goto err;
 
@@ -622,7 +624,7 @@ retry:
 		 */
 		res_counter_uncharge(&mem->res, PAGE_SIZE);
 		css_put(&mem->css);
-		kfree(pc);
+		kmem_cache_free(page_cgroup_cache, pc);
 		goto retry;
 	}
 	page_assign_page_cgroup(page, pc);
@@ -637,7 +639,7 @@ done:
 	return 0;
 out:
 	css_put(&mem->css);
-	kfree(pc);
+	kmem_cache_free(page_cgroup_cache, pc);
 err:
 	return -ENOMEM;
 }
@@ -695,7 +697,7 @@ void mem_cgroup_uncharge_page(struct pag
 		res_counter_uncharge(&mem->res, PAGE_SIZE);
 		css_put(&mem->css);
 
-		kfree(pc);
+		kmem_cache_free(page_cgroup_cache, pc);
 		return;
 	}
 
@@ -989,6 +991,7 @@ mem_cgroup_create(struct cgroup_subsys *
 	if (unlikely((cont->parent) == NULL)) {
 		mem = &init_mem_cgroup;
 		init_mm.mem_cgroup = mem;
+		page_cgroup_cache = KMEM_CACHE(page_cgroup, SLAB_PANIC);
 	} else
 		mem = kzalloc(sizeof(struct mem_cgroup), GFP_KERNEL);
 
_

-- 
	Warm Regards,
	Balbir Singh
	Linux Technology Center
	IBM, ISTL

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] Move memory controller allocations to their own slabs (v3)
  2008-03-13 14:03 [PATCH] Move memory controller allocations to their own slabs (v3) Balbir Singh
@ 2008-03-14  2:56 ` KAMEZAWA Hiroyuki
  2008-03-14 11:16   ` Hugh Dickins
  2008-03-17 11:25   ` Andy Whitcroft
  0 siblings, 2 replies; 4+ messages in thread
From: KAMEZAWA Hiroyuki @ 2008-03-14  2:56 UTC (permalink / raw)
  To: Balbir Singh
  Cc: Andrew Morton, Pavel Emelianov, Hugh Dickins, Sudhir Kumar,
	YAMAMOTO Takashi, Paul Menage, lizf, linux-kernel, taka,
	linux-mm, David Rientjes

On Thu, 13 Mar 2008 19:33:07 +0530
Balbir Singh <balbir@linux.vnet.ibm.com> wrote:

> 
> 
> Changelog v3
> 
> 1. Remove HWCACHE_ALIGN
> 
> Changelog v2
> 
> 1. Remove extra slab for mem_cgroup_per_zone
> 
> Move the memory controller data structure page_cgroup to its own slab cache.
> It saves space on the system, allocations are not necessarily pushed to order
> of 2 and should provide performance benefits. Users who disable the memory
> controller can also double check that the memory controller is not allocating
> page_cgroup's.
> 
> NOTE: Hugh Dickins brought up the issue of whether we want to mark page_cgroup
> as __GFP_MOVABLE or __GFP_RECLAIMABLE. I don't think there is an easy
> answer at the moment. page_cgroup's are associated with user pages,
> they can be reclaimed once the user page has been reclaimed, so it might
> make sense to mark them as __GFP_RECLAIMABLE. For now, I am leaving the
> marking to default values that the slab allocator uses.
> 
> Comments?
> 
At first, in my understanding,
- MOVABLE is for migratable pages. (so, not for kernel objects.)
- RECLAIMABLE is for reclaimable kernel objects. (for slab etc..)

All reclaimable objects are not necessary to be always reclaimable but
some amount of RECLAIMABLE objects (not all) should be recraimable easily.
For example, some of dentry-cache, inode-cache is reclaimable because *unused*
objects are cached.

When it comes to page_cgroup, *all* objects has dependency to pages which are
assigned to.  And user pages are reclaimable.
There is a similar object....the radix tree. radix-tree's node is allocated as
RECLAIMABLE object.

So I think it makes sense to changing page_cgroup to be reclaimable.

But final decision should be done by how fragmentation avoidance works.
It's good to test "how many hugepages can be allocated dynamically" when we
make page_cgroup to be GFP_RECAIMABLE 

Thanks,
-Kame



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] Move memory controller allocations to their own slabs (v3)
  2008-03-14  2:56 ` KAMEZAWA Hiroyuki
@ 2008-03-14 11:16   ` Hugh Dickins
  2008-03-17 11:25   ` Andy Whitcroft
  1 sibling, 0 replies; 4+ messages in thread
From: Hugh Dickins @ 2008-03-14 11:16 UTC (permalink / raw)
  To: KAMEZAWA Hiroyuki
  Cc: Balbir Singh, Andrew Morton, Pavel Emelianov, Sudhir Kumar,
	YAMAMOTO Takashi, Paul Menage, lizf, linux-kernel, taka,
	linux-mm, David Rientjes

On Fri, 14 Mar 2008, KAMEZAWA Hiroyuki wrote:
> At first, in my understanding,
> - MOVABLE is for migratable pages. (so, not for kernel objects.)
> - RECLAIMABLE is for reclaimable kernel objects. (for slab etc..)
> 
> All reclaimable objects are not necessary to be always reclaimable but
> some amount of RECLAIMABLE objects (not all) should be recraimable easily.
> For example, some of dentry-cache, inode-cache is reclaimable because *unused*
> objects are cached.
> 
> When it comes to page_cgroup, *all* objects has dependency to pages which are
> assigned to.  And user pages are reclaimable.
> There is a similar object....the radix tree. radix-tree's node is allocated as
> RECLAIMABLE object.
> 
> So I think it makes sense to changing page_cgroup to be reclaimable.
> 
> But final decision should be done by how fragmentation avoidance works.
> It's good to test "how many hugepages can be allocated dynamically" when we
> make page_cgroup to be GFP_RECAIMABLE 

I agree with you on all points.  No need for it to be done in the same
patch as Balbir's, but yes, __GFP_RECLAIMABLE appears to be appropriate
for the page_cgroup kmem_cache.

(I think it's a better fit than for the radix_tree_node cache: though
the common pagecache usage of the radix_tree implies that its nodes
are reclaimable, I can't see why radix_tree nodes would intrinsically
be reclaimable.  If a significant non-reclaimable user of radix-tree
comes on the scene, I'd expect us to change that assumption.)

Hugh

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] Move memory controller allocations to their own slabs (v3)
  2008-03-14  2:56 ` KAMEZAWA Hiroyuki
  2008-03-14 11:16   ` Hugh Dickins
@ 2008-03-17 11:25   ` Andy Whitcroft
  1 sibling, 0 replies; 4+ messages in thread
From: Andy Whitcroft @ 2008-03-17 11:25 UTC (permalink / raw)
  To: KAMEZAWA Hiroyuki
  Cc: Balbir Singh, Andrew Morton, Pavel Emelianov, Hugh Dickins,
	Sudhir Kumar, YAMAMOTO Takashi, Paul Menage, lizf, linux-kernel,
	taka, linux-mm, David Rientjes

On Fri, Mar 14, 2008 at 11:56:45AM +0900, KAMEZAWA Hiroyuki wrote:
> On Thu, 13 Mar 2008 19:33:07 +0530
> Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> 
> > 
> > 
> > Changelog v3
> > 
> > 1. Remove HWCACHE_ALIGN
> > 
> > Changelog v2
> > 
> > 1. Remove extra slab for mem_cgroup_per_zone
> > 
> > Move the memory controller data structure page_cgroup to its own slab cache.
> > It saves space on the system, allocations are not necessarily pushed to order
> > of 2 and should provide performance benefits. Users who disable the memory
> > controller can also double check that the memory controller is not allocating
> > page_cgroup's.
> > 
> > NOTE: Hugh Dickins brought up the issue of whether we want to mark page_cgroup
> > as __GFP_MOVABLE or __GFP_RECLAIMABLE. I don't think there is an easy
> > answer at the moment. page_cgroup's are associated with user pages,
> > they can be reclaimed once the user page has been reclaimed, so it might
> > make sense to mark them as __GFP_RECLAIMABLE. For now, I am leaving the
> > marking to default values that the slab allocator uses.
> > 
> > Comments?
> > 
> At first, in my understanding,
> - MOVABLE is for migratable pages. (so, not for kernel objects.)
> - RECLAIMABLE is for reclaimable kernel objects. (for slab etc..)

Yes, MOVABLE is for things which are very easily moved out, whether that
is migrated to another page, or paged out to swap, or trivially freed as
it can be re-read from somewhere such as text from a binary; generally
this is things on the LRU.

RECLAIMABLE, is things which are harder to get rid of, but for which
there is some hope of evicting their contents; as you say things like
those slab caches with shrinkers.

> All reclaimable objects are not necessary to be always reclaimable but
> some amount of RECLAIMABLE objects (not all) should be recraimable easily.
> For example, some of dentry-cache, inode-cache is reclaimable because *unused*
> objects are cached.
> 
> When it comes to page_cgroup, *all* objects has dependency to pages which are
> assigned to.  And user pages are reclaimable.
> There is a similar object....the radix tree. radix-tree's node is allocated as
> RECLAIMABLE object.
> 
> So I think it makes sense to changing page_cgroup to be reclaimable.

That sounds correct to me.

> But final decision should be done by how fragmentation avoidance works.
> It's good to test "how many hugepages can be allocated dynamically" when we
> make page_cgroup to be GFP_RECAIMABLE 

-apw

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2008-03-17 11:28 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-03-13 14:03 [PATCH] Move memory controller allocations to their own slabs (v3) Balbir Singh
2008-03-14  2:56 ` KAMEZAWA Hiroyuki
2008-03-14 11:16   ` Hugh Dickins
2008-03-17 11:25   ` Andy Whitcroft

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).