Re: [PATCH 28 of 30] memcg huge memory

[Balbir Singh <balbir@linux.vnet.ibm.com>]

* Andrea Arcangeli <aarcange@redhat.com> [2010-01-28 12:39:15]:

> On Wed, Jan 27, 2010 at 04:57:00PM +0530, Balbir Singh wrote:
> > On Friday 22 January 2010 05:43 AM, KAMEZAWA Hiroyuki wrote:
> > > 
> > >> Now the only real pain remains in the LRU list accounting, I tried to
> > >> solve it but found no clean way that didn't require mess all over
> > >> vmscan.c. So for now hugepages in lru are accounted as 4k pages
> > >> ;). Nothing breaks just stats won't be as useful to the admin...
> > >>
> > > Hmm, interesting/important problem...I keep it in my mind.
> > 
> > I hope the memcg accounting is not broken, I see you do the right thing
> > while charging pages. The patch overall seems alright. Could you please
> > update the Documentation/cgroups/memory.txt file as well with what these
> > changes mean and memcg_tests.txt to indicate how to test the changes?
> 
> Where exactly does that memory.txt go into the implementation details?
> Grepping the function names I changed over that file leads to
> nothing. It doesn't seem to be covering internals at all. The other
> file only place that shows some function names I could see needing an
> update is this:
> 
>      At try_charge(), there are no flags to say "this page is
>      charged".
>      at this point, usage += PAGE_SIZE.
> 
>      At commit(), the function checks the page should be charged or
>      not
>      and set flags or avoid charging.(usage -= PAGE_SIZE)
> 
>      At cancel(), simply usage -= PAGE_SIZE.
> 
> but it won't go into much more details than this, so I can only
> imagine to add this, explaining how the real page size is obtained and
> if I would go into the compound page accounting explanation that
> probably would bring it to a detail level that file didn't have in the
> first place.
> 

I would expect some Documentation stating the following

1. Impact of transparent hugepages on memcg
2. What does this mean to limit_in_bytes and usage_in_bytes and other
features
3. What does this mean for OOM, reclaim, etc, can there be some
side-effects.


> But again I'm very confused on what exactly you expect me to update on
> that file, so if below isn't ok best would be that you send me a patch
> to integrate with your signoff. That would be the preferred way to me.
>

I'll read through your patchset and see if I can come up with a useful
patch. 

-- 
	Balbir

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