Messages in this thread |  | | | Date | Tue, 09 Sep 2008 05:24:24 -0700 | | From | Balbir Singh <> | | Subject | Re: [RFC][PATCH] Remove cgroup member from struct page |
| |
KAMEZAWA Hiroyuki wrote: > On Tue, 9 Sep 2008 15:00:10 +1000 > Nick Piggin <nickpiggin@yahoo.com.au> wrote: >>> maybe a routine like SPARSEMEM is a choice. >>> >>> Following is pointer pre-allocation. (just pointer, not page_cgroup itself) >>> == >>> #define PCG_SECTION_SHIFT (10) >>> #define PCG_SECTION_SIZE (1 << PCG_SECTION_SHIFT) >>> >>> struct pcg_section { >>> struct page_cgroup **map[PCG_SECTION_SHIFT]; //array of pointer. >>> }; >>> >>> struct page_cgroup *get_page_cgroup(unsigned long pfn) >>> { >>> struct pcg_section *sec; >>> sec = pcg_section[(pfn >> PCG_SECTION_SHIFT)]; >>> return *sec->page_cgroup[(pfn & ((1 << PCG_SECTTION_SHIFT) - 1]; >>> } >>> == >>> If we go extreme, we can use kmap_atomic() for pointer array. >>> >>> Overhead of pointer-walk is not so bad, maybe. >>> >>> For 64bit systems, we can find a way like SPARSEMEM_VMEMMAP. >> Yes I too think that would be the ideal way to go to get the best of >> performance in the enabled case. However Balbir I believe is interested >> in memory savings if not all pages have cgroups... I don't know, I don't >> care so much about the "enabled" case, so I'll leave you two to fight it >> out :) >> > I'll add a new patch on my set. > > Balbir, are you ok to CONFIG_CGROUP_MEM_RES_CTLR depends on CONFIG_SPARSEMEM ? > I thinks SPARSEMEM(SPARSEMEM_VMEMMAP) is widely used in various archs now.
Can't we make it more generic. I was thinking of allocating memory for each node for page_cgroups (of the size of spanned_pages) at initialization time. I've not yet prototyped the idea. BTW, even with your approach I fail to see why we need to add a dependency on CONFIG_SPARSEMEM (but again it is 4:30 in the morning and I might be missing the obvious)
-- Balbir
|  |