Re: [RFC][PATCH] Clarify mem_cgroup lock handling and avoid races.

[KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>]

On Thu, 21 Feb 2008 11:49:29 +0900 (JST)
Hirokazu Takahashi <taka@valinux.co.jp> wrote:

> > We thought of this as well. We dropped it, because we need to track only user
> > pages at the moment. Doing it for all pages means having the overhead for each
> > page on the system.
> 
> Let me clarify that the overhead you said is you'll waste some memory
> whose pages are assigned for the kernel internal use, right?
> If so, it wouldn't be a big problem since most of the pages are assigned to
> process anonymous memory or to the page cache as Paul said.
> 
My idea is..
(1) It will be big waste of memory to pre-allocate all page_cgroup struct at
    boot.  Because following two will not need it.
    (1) kernel memory
    (2) HugeTLB memory
Mainly because of (2), I don't like pre-allocation.

But we'll be able to archive  pfn <-> page_cgroup relationship using
on-demand memmap style.
(Someone mentioned about using radix-tree in other thread.)

Balbir-san, I'd like to do some work aroung this becasue I've experience
sparsemem and memory hotplug developments.

Or have you already started ?

Thanks,
-Kame


--
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>