[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.10.1604181422220.23710@chino.kir.corp.google.com>
Date: Mon, 18 Apr 2016 14:23:58 -0700 (PDT)
From: David Rientjes <rientjes@...gle.com>
To: Michal Hocko <mhocko@...nel.org>
cc: Andrew Morton <akpm@...ux-foundation.org>,
Nikolay Borisov <kernel@...p.com>,
Johannes Weiner <hannes@...xchg.org>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [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.
Powered by blists - more mailing lists