Messages in this thread | | | Date | Thu, 3 Jul 2008 16:56:04 +0900 | From | KAMEZAWA Hiroyuki <> | Subject | Re: [RFC][PATCH] memcg: change shmem handler. |
| |
On Thu, 03 Jul 2008 12:45:14 +0530 Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> > This patch fixes some mess by > > - PAGE_CGROUP_FLAG_CACHE is deleted (and replaced by FLAG_FILE) > > - PAGE_CGROUP_FLAG_SHMEM is added. > > - add_to_page_cache_nocharge() is added. > > This avoids mem_cgroup_charge_cache_page(). This is useful when page is > > pre-charged. > > - uses add_to_page_cache_nocharge() also in hugemem. > > (I think hugemem controller should be independent from memcg. > > Balbir, how do you think ?) > > I am not 100% sure of that right now. I definitely want different control > parameters (not included as a part of memory.limit_in_bytes). If there is > leverage from memory controller, we could consider adding that to it or a > separate controller if that makes more sense. > Checking PG_compound in mem_cgroup_charge_cache_page() is enough, maybe. (If multi-page-file-cache is added, need rework ;)
> > - PageSwapBacked() is checked. > > (A imported patch from Hugh Dickins) > > > > As result. > > - shmem will be in SwapBacked/Active list at first. > > Good > > > - memcg has "shmem/tmpfs" counter. > > > > I think this will be useful too (but I need to play with it) > I've been argued that "if you want to add such a stupid counter, add the same parameter to global lru without any overhead."
I'll postpone this ;) I have many other thing to do.
But the total number of pages used for shmem is already counted by address_space->nr_pages. So, not very difficult for global lru if we can walk all inodes of shmem. The problem will be "whether it's worth to do or not"
Thanks, -Kame
| |