On Tue, 9 Sep 2008 13:58:27 +1000
Nick Piggin <nickpiggin@yahoo.com.au> wrote:

quoted text
> On Tuesday 09 September 2008 13:57, KAMEZAWA Hiroyuki wrote:
> > On Mon, 8 Sep 2008 20:58:10 +0530
> >
> > Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> > > Sorry for the delay in sending out the new patch, I am traveling and
> > > thus a little less responsive. Here is the update patch
> >
> > Hmm.. I've considered this approach for a while and my answer is that
> > this is not what you really want.
> >
> > Because you just moves the placement of pointer from memmap to
> > radix_tree both in GFP_KERNEL, total kernel memory usage is not changed.
> > So, at least, you have to add some address calculation (as I did in March)
> > to getting address of page_cgroup. But page_cgroup itself consumes 32bytes
> > per page. Then.....
> 
> Just keep in mind that an important point is to make it more attractive
> to configure cgroup into the kernel, but have it disabled or unused at
> runtime.
> 

Hmm..kicking out 4bytes per 4096bytes if disabled ?

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.

Thanks,
-Kame




Thanks,
-Kame

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/