[Cc cgroups maintainers]
On Wed 28-08-19 10:58:00, Mina Almasry wrote:
> On Wed, Aug 28, 2019 at 4:23 AM Michal Hocko <mhocko@xxxxxxxxxx> wrote:
> >
> > On Mon 26-08-19 16:32:34, Mina Almasry wrote:
> > > mm/hugetlb.c | 493 ++++++++++++------
> > > mm/hugetlb_cgroup.c | 187 +++++--
> >
> > This is a lot of changes to an already subtle code which hugetlb
> > reservations undoubly are.
>
> For what it's worth, I think this patch series is a net decrease in
> the complexity of the reservation code, especially the region_*
> functions, which is where a lot of the complexity lies. I removed the
> race between region_del and region_{add|chg}, refactored the main
> logic into smaller code, moved common code to helpers and deleted the
> duplicates, and finally added lots of comments to the hard to
> understand pieces. I hope that when folks review the changes they will
> see that! :)
Post those improvements as standalone patches and sell them as
improvements. We can talk about the net additional complexity of the
controller much easier then.
> > Moreover cgroupv1 is feature frozen and I am
> > not aware of any plans to port the controller to v2.
>
> Also for what it's worth, if porting the controller to v2 is a
> requisite to take this, I'm happy to do that. As far as I understand
> there is no reason hugetlb_cgroups shouldn't be in cgroups v2, and we
> see value in them.
Talk to cgroups maintainers why the hugegetlb controller hasn't been
enabled in v2. All I am saing is that v1 only features are really a hard
sell. Even without adding a lot of code to hugetlb which is quite
complex on its own.
--
Michal Hocko
SUSE Labs
