[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190809112738.GB13061@blackbody.suse.cz>
Date: Fri, 9 Aug 2019 13:27:39 +0200
From: Michal Koutný <mkoutny@...e.com>
To: Mina Almasry <almasrymina@...gle.com>
Cc: mike.kravetz@...cle.com, shuah@...nel.org, rientjes@...gle.com,
shakeelb@...gle.com, gthelen@...gle.com, akpm@...ux-foundation.org,
khalid.aziz@...cle.com, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, linux-kselftest@...r.kernel.org,
cgroups@...r.kernel.org
Subject: Re: [RFC PATCH] hugetlbfs: Add hugetlb_cgroup reservation limits
(+CC cgroups@...r.kernel.org)
On Thu, Aug 08, 2019 at 12:40:02PM -0700, Mina Almasry <almasrymina@...gle.com> wrote:
> We have developers interested in using hugetlb_cgroups, and they have expressed
> dissatisfaction regarding this behavior.
I assume you still want to enforce a limit on a particular group and the
application must be able to handle resource scarcity (but better
notified than SIGBUS).
> Alternatives considered:
> [...]
(I did not try that but) have you considered:
3) MAP_POPULATE while you're making the reservation,
4) Using multple hugetlbfs mounts with respective limits.
> Caveats:
> 1. This support is implemented for cgroups-v1. I have not tried
> hugetlb_cgroups with cgroups v2, and AFAICT it's not supported yet.
> This is largely because we use cgroups-v1 for now.
Adding something new into v1 without v2 counterpart, is making migration
harder, that's one of the reasons why v1 API is rather frozen now. (I'm
not sure whether current hugetlb controller fits into v2 at all though.)
Michal
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists