On Fri, 01 Oct 2010 11:41:07 -0500 "Steven J. Magnani" <steve@xxxxxxxxxxxxxxx> wrote: > > However, I suppose there's little harm in letting the patch in. I would guess > > the additions all optimise away if memcg isn't enabled. > > > > A question for you: why does struct page_cgroup need a page pointer? If an > > array of page_cgroup structs is allocated per array of page structs, then you > > should be able to use the array index to map between them. > No reason. It was not array in the 1st implemenation and ->page still remains. At 2nd implementation, I didn't know embeded people has any interests on memcg. And I wasn't sure how page_cgroup_to_page() : pfn_to_page(pagec_cgroup_to_pfn(pc)) will be widely used. Now, we know page_cgroup->page is not used in very critical path _if_ node-id and zone-id can be directly got from page_cgroup. I'm now preparing a patch to remove struct page* pointer. I'm wondering whether it's ok that some architecuture cannot drop struct page pointer. If SPARSEMEM is used on 32bit arch, I'm not sure whether # of bits isn't enough. I may have to add overhead to get nid, zid in critical path. (for example, s390/32bit, x86-32/HIGHMEM, ARM/HIGHMEM?) Current out priority is supporting dirty_ratio rather than memory usage diet. Please wait. Removing page_cgroup->page patch will add something a bit complex. Thanks, -Kame -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>