David Rientjes <rient...@google.com> writes: > Memcg aligns memory.limit_in_bytes to PAGE_SIZE as part of the resource > counter > since it makes no sense to allow a partial page to be charged. > > As a result of the hugetlb cgroup using the resource counter, it is also > aligned > to PAGE_SIZE but makes no sense unless aligned to the size of the hugepage > being > limited. > > Align hugetlb cgroup limit to hugepage size. > > Acked-by: Michal Hocko <mho...@suse.cz> > Signed-off-by: David Rientjes <rient...@google.com>
Reviewed-by: Aneesh Kumar K.V <aneesh.ku...@linux.vnet.ibm.com> > --- > v2: use huge_page_order() per Aneesh > Sorry for not cc'ing you initially, get_maintainer.pl failed me > > mm/hugetlb_cgroup.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/mm/hugetlb_cgroup.c b/mm/hugetlb_cgroup.c > --- a/mm/hugetlb_cgroup.c > +++ b/mm/hugetlb_cgroup.c > @@ -275,6 +275,7 @@ static ssize_t hugetlb_cgroup_write(struct > kernfs_open_file *of, > ret = res_counter_memparse_write_strategy(buf, &val); > if (ret) > break; > + val = ALIGN(val, 1ULL << huge_page_shift(&hstates[idx])); Do we really need ULL ? max value should fit in unsigned long right ? > ret = res_counter_set_limit(&h_cg->hugepage[idx], val); > break; > default: -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
