lkml.org 
[lkml]   [2016]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch v2] mm, hugetlb_cgroup: round limit_in_bytes down to hugepage size
On Fri, 15 Apr 2016, Michal Hocko wrote:

> > > > +static void hugetlb_cgroup_init(struct hugetlb_cgroup *h_cgroup,
> > > > + struct hugetlb_cgroup *parent_h_cgroup)
> > > > +{
> > > > + int idx;
> > > > +
> > > > + for (idx = 0; idx < HUGE_MAX_HSTATE; idx++) {
> > > > + struct page_counter *counter = &h_cgroup->hugepage[idx];
> > > > + struct page_counter *parent = NULL;
> > > > + unsigned long limit;
> > > > + int ret;
> > > > +
> > > > + if (parent_h_cgroup)
> > > > + parent = &parent_h_cgroup->hugepage[idx];
> > > > + page_counter_init(counter, parent);
> > > > +
> > > > + limit = round_down(PAGE_COUNTER_MAX,
> > > > + 1 << huge_page_order(&hstates[idx]));
> > > > + ret = page_counter_limit(counter, limit);
> > > > + VM_BUG_ON(ret);
> > > > + }
> > > > +}
> > >
> > > I fail to see the point for this. Why would want to round down
> > > PAGE_COUNTER_MAX? It will never make a real difference. Or am I missing
> > > something?
> >
> > Did you try the patch?
> >
> > If we're rounding down the user value, it makes sense to be consistent
> > with the upper bound default to specify intent.
>
> The point I've tried to raise is why do we care and add a code if we can
> never reach that value? Does actually anybody checks for the alignment.

If the user modifies the value successfully, it can never be restored to
the default since the write handler rounds down. It's a matter of
consistency for a long-term maintainable kernel and prevents bug reports.

\
 
 \ /
  Last update: 2016-04-18 23:41    [W:0.056 / U:0.300 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site