From: "Michal Koutný" <mkoutny@suse.com>
To: Mina Almasry <almasrymina@google.com>
Cc: mike.kravetz@oracle.com, shuah@kernel.org, rientjes@google.com,
shakeelb@google.com, gthelen@google.com,
akpm@linux-foundation.org, khalid.aziz@oracle.com,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-kselftest@vger.kernel.org, cgroups@vger.kernel.org
Subject: Re: [RFC PATCH] hugetlbfs: Add hugetlb_cgroup reservation limits
Date: Fri, 9 Aug 2019 13:27:39 +0200 [thread overview]
Message-ID: <20190809112738.GB13061@blackbody.suse.cz> (raw)
In-Reply-To: <20190808194002.226688-1-almasrymina@google.com>
[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]
(+CC cgroups@vger.kernel.org)
On Thu, Aug 08, 2019 at 12:40:02PM -0700, Mina Almasry <almasrymina@google.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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2019-08-09 11:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-08 19:40 Mina Almasry
2019-08-08 20:23 ` shuah
2019-08-08 21:28 ` Mina Almasry
2019-08-09 11:27 ` Michal Koutný [this message]
2019-08-09 18:05 ` Mina Almasry
2019-08-09 20:38 ` Mike Kravetz
2019-08-09 20:57 ` Mina Almasry
2019-08-09 21:00 ` Mike Kravetz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190809112738.GB13061@blackbody.suse.cz \
--to=mkoutny@suse.com \
--cc=akpm@linux-foundation.org \
--cc=almasrymina@google.com \
--cc=cgroups@vger.kernel.org \
--cc=gthelen@google.com \
--cc=khalid.aziz@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
--cc=rientjes@google.com \
--cc=shakeelb@google.com \
--cc=shuah@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox