Re: [patch] mm: memcontrol: lockless page counters

[Johannes Weiner <hannes@cmpxchg.org>]

On Mon, Sep 22, 2014 at 07:28:00PM +0200, Michal Hocko wrote:
> On Mon 22-09-14 11:50:49, Johannes Weiner wrote:
> > On Mon, Sep 22, 2014 at 04:44:36PM +0200, Michal Hocko wrote:
> > > On Fri 19-09-14 09:22:08, Johannes Weiner wrote:
> [...]
> > > Nevertheless I think that the counter should live outside of memcg (it
> > > is ugly and bad in general to make HUGETLB controller depend on MEMCG
> > > just to have a counter). If you made kernel/page_counter.c and led both
> > > containers select CONFIG_PAGE_COUNTER then you do not need a dependency
> > > on MEMCG and I would find it cleaner in general.
> > 
> > The reason I did it this way is because the hugetlb controller simply
> > accounts and limits a certain type of memory and in the future I would
> > like to make it a memcg extension, just like kmem and swap.
> 
> I am not sure this is the right way to go. Hugetlb has always been
> "special" and I do not see any advantage to pull its specialness into
> memcg proper.
>
> It would just make the code more complicated. I can also imagine
> users who simply do not want to pay memcg overhead and use only
> hugetlb controller.

We already group user memory, kernel memory, and swap space together,
what makes hugetlb-backed memory special?

It's much easier to organize the code if all those closely related
things are grouped together.  It's also better for the user interface
to have a single memory controller.

We're also close to the point where we don't differentiate between the
root group and dedicated groups in terms of performance, Dave's tests
fell apart at fairly high concurrency, and I'm already getting rid of
the lock he saw contended.

The downsides of fragmenting our configuration- and testspace, our
user interface, and our code base by far outweigh the benefits of
offering a dedicated hugetlb controller.