From: Mina Almasry <almasrymina@google.com> To: mike.kravetz@oracle.com, rientjes@google.com, shakeelb@google.com Cc: shuah@kernel.org, almasrymina@google.com, gthelen@google.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, cgroups@vger.kernel.org, aneesh.kumar@linux.vnet.ibm.com Subject: [PATCH v10 8/8] hugetlb_cgroup: Add hugetlb_cgroup reservation docs Date: Tue, 14 Jan 2020 17:26:51 -0800 Message-ID: <20200115012651.228058-8-almasrymina@google.com> (raw) In-Reply-To: <20200115012651.228058-1-almasrymina@google.com> Add docs for how to use hugetlb_cgroup reservations, and their behavior. Signed-off-by: Mina Almasry <almasrymina@google.com> --- Changes in v10: - Clarify reparenting behavior. - Reword benefits of reservation limits. Changes in v6: - Updated docs to reflect the new design based on a new counter that tracks both reservations and faults. --- .../admin-guide/cgroup-v1/hugetlb.rst | 103 ++++++++++++++++-- 1 file changed, 92 insertions(+), 11 deletions(-) diff --git a/Documentation/admin-guide/cgroup-v1/hugetlb.rst b/Documentation/admin-guide/cgroup-v1/hugetlb.rst index a3902aa253a96..00dd4daf55f19 100644 --- a/Documentation/admin-guide/cgroup-v1/hugetlb.rst +++ b/Documentation/admin-guide/cgroup-v1/hugetlb.rst @@ -2,13 +2,6 @@ HugeTLB Controller ================== -The HugeTLB controller allows to limit the HugeTLB usage per control group and -enforces the controller limit during page fault. Since HugeTLB doesn't -support page reclaim, enforcing the limit at page fault time implies that, -the application will get SIGBUS signal if it tries to access HugeTLB pages -beyond its limit. This requires the application to know beforehand how much -HugeTLB pages it would require for its use. - HugeTLB controller can be created by first mounting the cgroup filesystem. # mount -t cgroup -o hugetlb none /sys/fs/cgroup @@ -28,10 +21,14 @@ process (bash) into it. Brief summary of control files:: - hugetlb.<hugepagesize>.limit_in_bytes # set/show limit of "hugepagesize" hugetlb usage - hugetlb.<hugepagesize>.max_usage_in_bytes # show max "hugepagesize" hugetlb usage recorded - hugetlb.<hugepagesize>.usage_in_bytes # show current usage for "hugepagesize" hugetlb - hugetlb.<hugepagesize>.failcnt # show the number of allocation failure due to HugeTLB limit + hugetlb.<hugepagesize>.resv.limit_in_bytes # set/show limit of "hugepagesize" hugetlb reservations + hugetlb.<hugepagesize>.resv.max_usage_in_bytes # show max "hugepagesize" hugetlb reservations and no-reserve faults + hugetlb.<hugepagesize>.resv.usage_in_bytes # show current reservations and no-reserve faults for "hugepagesize" hugetlb + hugetlb.<hugepagesize>.resv.failcnt # show the number of allocation failure due to HugeTLB reservation limit + hugetlb.<hugepagesize>.limit_in_bytes # set/show limit of "hugepagesize" hugetlb faults + hugetlb.<hugepagesize>.max_usage_in_bytes # show max "hugepagesize" hugetlb usage recorded + hugetlb.<hugepagesize>.usage_in_bytes # show current usage for "hugepagesize" hugetlb + hugetlb.<hugepagesize>.failcnt # show the number of allocation failure due to HugeTLB usage limit For a system supporting three hugepage sizes (64k, 32M and 1G), the control files include:: @@ -40,11 +37,95 @@ files include:: hugetlb.1GB.max_usage_in_bytes hugetlb.1GB.usage_in_bytes hugetlb.1GB.failcnt + hugetlb.1GB.resv.limit_in_bytes + hugetlb.1GB.resv.max_usage_in_bytes + hugetlb.1GB.resv.usage_in_bytes + hugetlb.1GB.resv.failcnt hugetlb.64KB.limit_in_bytes hugetlb.64KB.max_usage_in_bytes hugetlb.64KB.usage_in_bytes hugetlb.64KB.failcnt + hugetlb.64KB.resv.limit_in_bytes + hugetlb.64KB.resv.max_usage_in_bytes + hugetlb.64KB.resv.usage_in_bytes + hugetlb.64KB.resv.failcnt hugetlb.32MB.limit_in_bytes hugetlb.32MB.max_usage_in_bytes hugetlb.32MB.usage_in_bytes hugetlb.32MB.failcnt + hugetlb.32MB.resv.limit_in_bytes + hugetlb.32MB.resv.max_usage_in_bytes + hugetlb.32MB.resv.usage_in_bytes + hugetlb.32MB.resv.failcnt + + +1. Page fault accounting + +hugetlb.<hugepagesize>.limit_in_bytes +hugetlb.<hugepagesize>.max_usage_in_bytes +hugetlb.<hugepagesize>.usage_in_bytes +hugetlb.<hugepagesize>.failcnt + +The HugeTLB controller allows users to limit the HugeTLB usage (page fault) per +control group and enforces the limit during page fault. Since HugeTLB +doesn't support page reclaim, enforcing the limit at page fault time implies +that, the application will get SIGBUS signal if it tries to fault in HugeTLB +pages beyond its limit. Therefore the application needs to know exactly how many +HugeTLB pages it uses before hand, and the sysadmin needs to make sure that +there are enough available on the machine for all the users to avoid processes +getting SIGBUS. + + +2. Reservation accounting + +hugetlb.<hugepagesize>.resv.limit_in_bytes +hugetlb.<hugepagesize>.resv.max_usage_in_bytes +hugetlb.<hugepagesize>.resv.usage_in_bytes +hugetlb.<hugepagesize>.resv.failcnt + +The HugeTLB controller allows to limit the HugeTLB reservations per control +group and enforces the controller limit at reservation time and at the fault of +HugeTLB memory for which no reservation exists. Since reservation limits are +enforced at reservation time (on mmap or shget), reservation limits never causes +the application to get SIGBUS signal if the memory was reserved before hand. For +MAP_NORESERVE allocations, the reservation limit behaves the same as the fault +limit, enforcing memory usage at fault time and causing the application to +receive a SIGBUS if it's crossing its limit. + +Reservation limits are superior to page fault limits described above, since +reservation limits are enforced at reservation time (on mmap or shget), and +never causes the application to get SIGBUS signal if the memory was reserved +before hand. This allows for easier fallback to alternatives such as +non-HugeTLB memory for example. In the case of page fault accounting, it's very +hard to avoid processes getting SIGBUS since the sysadmin needs precisely know +the HugeTLB usage of all the tasks in the system and make sure there is enough +pages to satisfy all requests. Avoiding tasks getting SIGBUS on overcommited +systems is practically impossible with page fault accounting. + + +3. Caveats with shared memory + +For shared HugeTLB memory, both HugeTLB reservation and page faults are charged +to the first task that causes the memory to be reserved or faulted, and all +subsequent uses of this reserved or faulted memory is done without charging. + +Shared HugeTLB memory is only uncharged when it is unreserved or deallocated. +This is usually when the HugeTLB file is deleted, and not when the task that +caused the reservation or fault has exited. + + +4. Caveats with HugeTLB cgroup offline. + +When a HugeTLB cgroup goes offline with some reservations or faults still +charged to it, the behavior is as follows: + +- The fault charges are charged to the parent HugeTLB cgroup (reparented), +- the reservation charges remain on the offline HugeTLB cgroup. + +This means that if a HugeTLB cgroup gets offlined while there is still HugeTLB +reservations charged to it, that cgroup persists as a zombie until all HugeTLB +reservations are uncharged. HugeTLB reservations behave in this manner to match +the memory controller whose cgroups also persist as zombie until all charged +memory is uncharged. Also, the tracking of HugeTLB reservations is a bit more +complex compared to the tracking of HugeTLB faults, so it is significantly +harder to reparent reservations at offline time. -- 2.25.0.rc1.283.g88dfdc4193-goog
next prev parent reply index Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-01-15 1:26 [PATCH v10 1/8] hugetlb_cgroup: Add hugetlb_cgroup reservation counter Mina Almasry 2020-01-15 1:26 ` [PATCH v10 2/8] hugetlb_cgroup: add interface for charge/uncharge hugetlb reservations Mina Almasry 2020-01-17 19:26 ` Mike Kravetz 2020-01-17 19:34 ` Mina Almasry 2020-01-29 21:21 ` David Rientjes 2020-01-30 0:41 ` Mike Kravetz 2020-01-15 1:26 ` [PATCH v10 3/8] hugetlb_cgroup: add reservation accounting for private mappings Mina Almasry 2020-01-17 22:57 ` Mike Kravetz 2020-01-29 21:28 ` David Rientjes 2020-02-03 23:17 ` Mina Almasry 2020-01-15 1:26 ` [PATCH v10 4/8] hugetlb: disable region_add file_region coalescing Mina Almasry 2020-01-21 18:50 ` Mike Kravetz 2020-01-15 1:26 ` [PATCH v10 5/8] hugetlb_cgroup: add accounting for shared mappings Mina Almasry 2020-01-15 1:26 ` [PATCH v10 6/8] hugetlb_cgroup: support noreserve mappings Mina Almasry 2020-01-15 1:26 ` [PATCH v10 7/8] hugetlb_cgroup: Add hugetlb_cgroup reservation tests Mina Almasry 2020-01-23 9:15 ` Sandipan Das 2020-01-23 20:05 ` Mina Almasry 2020-01-29 21:00 ` David Rientjes 2020-01-30 6:11 ` Sandipan Das 2020-02-03 23:18 ` Mina Almasry 2020-01-15 1:26 ` Mina Almasry [this message] 2020-01-16 22:44 ` [PATCH v10 1/8] hugetlb_cgroup: Add hugetlb_cgroup reservation counter Mike Kravetz 2020-01-29 21:09 ` David Rientjes 2020-02-03 23:16 ` Mina Almasry
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=20200115012651.228058-8-almasrymina@google.com \ --to=almasrymina@google.com \ --cc=akpm@linux-foundation.org \ --cc=aneesh.kumar@linux.vnet.ibm.com \ --cc=cgroups@vger.kernel.org \ --cc=gthelen@google.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
Linux-kselftest Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-kselftest/0 linux-kselftest/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-kselftest linux-kselftest/ https://lore.kernel.org/linux-kselftest \ linux-kselftest@vger.kernel.org public-inbox-index linux-kselftest Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kselftest AGPL code for this site: git clone https://public-inbox.org/public-inbox.git