On Mon, Sep 22, 2014 at 07:28:00PM +0200, Michal Hocko wrote:

On Mon 22-09-14 11:50:49, Johannes Weiner wrote:

quoted

On Mon, Sep 22, 2014 at 04:44:36PM +0200, Michal Hocko wrote:

quoted

On Fri 19-09-14 09:22:08, Johannes Weiner wrote:

[...]

quoted

quoted

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.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>