lkml.org 
[lkml]   [2012]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH -V3 2/8] memcg: Add HugeTLB extension
Date
On Tue, 13 Mar 2012 14:33:16 -0700, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Tue, 13 Mar 2012 12:37:06 +0530
> "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> wrote:
>
> > +static int mem_cgroup_hugetlb_usage(struct mem_cgroup *memcg)
> > +{
> > + int idx;
> > + for (idx = 0; idx < hugetlb_max_hstate; idx++) {
> > + if (memcg->hugepage[idx].usage > 0)
> > + return memcg->hugepage[idx].usage;
> > + }
> > + return 0;
> > +}
>
> Please document the function? Had you done this, I might have been
> able to work out why the function bales out on the first used hugepage
> size, but I can't :(

I guess the function is named wrongly. I will rename it to
mem_cgroup_have_hugetlb_usage() in the next iteration ? The function
will return (bool) 1 if it has any hugetlb resource usage.

>
> This could have used for_each_hstate(), had that macro been better
> designed (or updated).
>

Can you explain this ?. for_each_hstate allows to iterate over
different hstates. But here we need to look at different hugepage
rescounter in memcg. I can still use for_each_hstate() and find the
hstate index (h - hstates) and use that to index memcg rescounter
array. But that would make it more complex ?

> Upon return this function coerces an unsigned long long into an "int".
> We decided last week that more than 2^32 hugepages was not
> inconceivable, so I guess that's a bug.
>

-aneesh



\
 
 \ /
  Last update: 2012-03-14 11:25    [W:0.050 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site