2012-08-01 03:42:12 +04:00
|
|
|
/*
|
|
|
|
|
* Copyright IBM Corporation, 2012
|
|
|
|
|
* Author Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
|
|
|
|
|
*
|
|
|
|
|
* This program is free software; you can redistribute it and/or modify it
|
|
|
|
|
* under the terms of version 2.1 of the GNU Lesser General Public License
|
|
|
|
|
* as published by the Free Software Foundation.
|
|
|
|
|
*
|
|
|
|
|
* This program is distributed in the hope that it would be useful, but
|
|
|
|
|
* WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
|
|
|
|
|
*
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef _LINUX_HUGETLB_CGROUP_H
|
|
|
|
|
#define _LINUX_HUGETLB_CGROUP_H
|
|
|
|
|
|
2014-01-24 03:52:54 +04:00
|
|
|
#include <linux/mmdebug.h>
|
2012-08-01 03:42:12 +04:00
|
|
|
|
|
|
|
|
struct hugetlb_cgroup;
|
2020-04-02 07:11:21 +03:00
|
|
|
struct resv_map;
|
hugetlb_cgroup: add accounting for shared mappings
For shared mappings, the pointer to the hugetlb_cgroup to uncharge lives
in the resv_map entries, in file_region->reservation_counter.
After a call to region_chg, we charge the approprate hugetlb_cgroup, and
if successful, we pass on the hugetlb_cgroup info to a follow up
region_add call. When a file_region entry is added to the resv_map via
region_add, we put the pointer to that cgroup in
file_region->reservation_counter. If charging doesn't succeed, we report
the error to the caller, so that the kernel fails the reservation.
On region_del, which is when the hugetlb memory is unreserved, we also
uncharge the file_region->reservation_counter.
[akpm@linux-foundation.org: forward declare struct file_region]
Signed-off-by: Mina Almasry <almasrymina@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Sandipan Das <sandipan@linux.ibm.com>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Shuah Khan <shuah@kernel.org>
Link: http://lkml.kernel.org/r/20200211213128.73302-5-almasrymina@google.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-04-02 07:11:28 +03:00
|
|
|
struct file_region;
|
2020-04-02 07:11:21 +03:00
|
|
|
|
2021-07-01 04:47:09 +03:00
|
|
|
#ifdef CONFIG_CGROUP_HUGETLB
|
2012-08-01 03:42:15 +04:00
|
|
|
/*
|
|
|
|
|
* Minimum page order trackable by hugetlb cgroup.
|
mm,hugetlb: use folio fields in second tail page
Patch series "mm,huge,rmap: unify and speed up compound mapcounts".
This patch (of 3):
We want to declare one more int in the first tail of a compound page: that
first tail page being valuable property, since every compound page has a
first tail, but perhaps no more than that.
No problem on 64-bit: there is already space for it. No problem with
32-bit THPs: 5.18 commit 5232c63f46fd ("mm: Make compound_pincount always
available") kindly cleared the space for it, apparently not realizing that
only 64-bit architectures enable CONFIG_THP_SWAP (whose use of tail
page->private might conflict) - but make sure of that in its Kconfig.
But hugetlb pages use tail page->private of the first tail page for a
subpool pointer, which will conflict; and they also use page->private of
the 2nd, 3rd and 4th tails.
Undo "mm: add private field of first tail to struct page and struct
folio"'s recent addition of private_1 to the folio tail: instead add
hugetlb_subpool, hugetlb_cgroup, hugetlb_cgroup_rsvd, hugetlb_hwpoison to
a second tail page of the folio: THP has long been using several fields of
that tail, so make better use of it for hugetlb too. This is not how a
generic folio should be declared in future, but it is an effective
transitional way to make use of it.
Delete the SUBPAGE_INDEX stuff, but keep __NR_USED_SUBPAGE: now 3.
[hughd@google.com: prefix folio's page_1 and page_2 with double underscore,
give folio's _flags_2 and _head_2 a line documentation each]
Link: https://lkml.kernel.org/r/9e2cb6b-5b58-d3f2-b5ee-5f8a14e8f10@google.com
Link: https://lkml.kernel.org/r/5f52de70-975-e94f-f141-543765736181@google.com
Link: https://lkml.kernel.org/r/3818cc9a-9999-d064-d778-9c94c5911e6@google.com
Signed-off-by: Hugh Dickins <hughd@google.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: James Houghton <jthoughton@google.com>
Cc: John Hubbard <jhubbard@nvidia.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Mina Almasry <almasrymina@google.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Naoya Horiguchi <naoya.horiguchi@linux.dev>
Cc: Peter Xu <peterx@redhat.com>
Cc: Sidhartha Kumar <sidhartha.kumar@oracle.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Yang Shi <shy828301@gmail.com>
Cc: Zach O'Keefe <zokeefe@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-11-03 04:48:45 +03:00
|
|
|
* At least 3 pages are necessary for all the tracking information.
|
|
|
|
|
* The second tail page contains all of the hugetlb-specific fields.
|
2012-08-01 03:42:15 +04:00
|
|
|
*/
|
mm,hugetlb: use folio fields in second tail page
Patch series "mm,huge,rmap: unify and speed up compound mapcounts".
This patch (of 3):
We want to declare one more int in the first tail of a compound page: that
first tail page being valuable property, since every compound page has a
first tail, but perhaps no more than that.
No problem on 64-bit: there is already space for it. No problem with
32-bit THPs: 5.18 commit 5232c63f46fd ("mm: Make compound_pincount always
available") kindly cleared the space for it, apparently not realizing that
only 64-bit architectures enable CONFIG_THP_SWAP (whose use of tail
page->private might conflict) - but make sure of that in its Kconfig.
But hugetlb pages use tail page->private of the first tail page for a
subpool pointer, which will conflict; and they also use page->private of
the 2nd, 3rd and 4th tails.
Undo "mm: add private field of first tail to struct page and struct
folio"'s recent addition of private_1 to the folio tail: instead add
hugetlb_subpool, hugetlb_cgroup, hugetlb_cgroup_rsvd, hugetlb_hwpoison to
a second tail page of the folio: THP has long been using several fields of
that tail, so make better use of it for hugetlb too. This is not how a
generic folio should be declared in future, but it is an effective
transitional way to make use of it.
Delete the SUBPAGE_INDEX stuff, but keep __NR_USED_SUBPAGE: now 3.
[hughd@google.com: prefix folio's page_1 and page_2 with double underscore,
give folio's _flags_2 and _head_2 a line documentation each]
Link: https://lkml.kernel.org/r/9e2cb6b-5b58-d3f2-b5ee-5f8a14e8f10@google.com
Link: https://lkml.kernel.org/r/5f52de70-975-e94f-f141-543765736181@google.com
Link: https://lkml.kernel.org/r/3818cc9a-9999-d064-d778-9c94c5911e6@google.com
Signed-off-by: Hugh Dickins <hughd@google.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: James Houghton <jthoughton@google.com>
Cc: John Hubbard <jhubbard@nvidia.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Mina Almasry <almasrymina@google.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Naoya Horiguchi <naoya.horiguchi@linux.dev>
Cc: Peter Xu <peterx@redhat.com>
Cc: Sidhartha Kumar <sidhartha.kumar@oracle.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Yang Shi <shy828301@gmail.com>
Cc: Zach O'Keefe <zokeefe@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-11-03 04:48:45 +03:00
|
|
|
#define HUGETLB_CGROUP_MIN_ORDER order_base_2(__NR_USED_SUBPAGE)
|
2012-08-01 03:42:12 +04:00
|
|
|
|
2020-04-02 07:11:21 +03:00
|
|
|
enum hugetlb_memory_event {
|
|
|
|
|
HUGETLB_MAX,
|
|
|
|
|
HUGETLB_NR_MEMORY_EVENTS,
|
|
|
|
|
};
|
|
|
|
|
|
2022-01-15 01:07:48 +03:00
|
|
|
struct hugetlb_cgroup_per_node {
|
|
|
|
|
/* hugetlb usage in pages over all hstates. */
|
|
|
|
|
unsigned long usage[HUGE_MAX_HSTATE];
|
|
|
|
|
};
|
|
|
|
|
|
2020-04-02 07:11:21 +03:00
|
|
|
struct hugetlb_cgroup {
|
|
|
|
|
struct cgroup_subsys_state css;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* the counter to account for hugepages from hugetlb.
|
|
|
|
|
*/
|
|
|
|
|
struct page_counter hugepage[HUGE_MAX_HSTATE];
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* the counter to account for hugepage reservations from hugetlb.
|
|
|
|
|
*/
|
|
|
|
|
struct page_counter rsvd_hugepage[HUGE_MAX_HSTATE];
|
|
|
|
|
|
|
|
|
|
atomic_long_t events[HUGE_MAX_HSTATE][HUGETLB_NR_MEMORY_EVENTS];
|
|
|
|
|
atomic_long_t events_local[HUGE_MAX_HSTATE][HUGETLB_NR_MEMORY_EVENTS];
|
|
|
|
|
|
|
|
|
|
/* Handle for "hugetlb.events" */
|
|
|
|
|
struct cgroup_file events_file[HUGE_MAX_HSTATE];
|
|
|
|
|
|
|
|
|
|
/* Handle for "hugetlb.events.local" */
|
|
|
|
|
struct cgroup_file events_local_file[HUGE_MAX_HSTATE];
|
2022-01-15 01:07:48 +03:00
|
|
|
|
|
|
|
|
struct hugetlb_cgroup_per_node *nodeinfo[];
|
2020-04-02 07:11:21 +03:00
|
|
|
};
|
2012-08-01 03:42:15 +04:00
|
|
|
|
2020-04-02 07:11:15 +03:00
|
|
|
static inline struct hugetlb_cgroup *
|
2022-11-02 01:30:52 +03:00
|
|
|
__hugetlb_cgroup_from_folio(struct folio *folio, bool rsvd)
|
2012-08-01 03:42:15 +04:00
|
|
|
{
|
2022-11-02 01:30:52 +03:00
|
|
|
VM_BUG_ON_FOLIO(!folio_test_hugetlb(folio), folio);
|
|
|
|
|
if (folio_order(folio) < HUGETLB_CGROUP_MIN_ORDER)
|
2012-08-01 03:42:15 +04:00
|
|
|
return NULL;
|
mm,hugetlb: use folio fields in second tail page
Patch series "mm,huge,rmap: unify and speed up compound mapcounts".
This patch (of 3):
We want to declare one more int in the first tail of a compound page: that
first tail page being valuable property, since every compound page has a
first tail, but perhaps no more than that.
No problem on 64-bit: there is already space for it. No problem with
32-bit THPs: 5.18 commit 5232c63f46fd ("mm: Make compound_pincount always
available") kindly cleared the space for it, apparently not realizing that
only 64-bit architectures enable CONFIG_THP_SWAP (whose use of tail
page->private might conflict) - but make sure of that in its Kconfig.
But hugetlb pages use tail page->private of the first tail page for a
subpool pointer, which will conflict; and they also use page->private of
the 2nd, 3rd and 4th tails.
Undo "mm: add private field of first tail to struct page and struct
folio"'s recent addition of private_1 to the folio tail: instead add
hugetlb_subpool, hugetlb_cgroup, hugetlb_cgroup_rsvd, hugetlb_hwpoison to
a second tail page of the folio: THP has long been using several fields of
that tail, so make better use of it for hugetlb too. This is not how a
generic folio should be declared in future, but it is an effective
transitional way to make use of it.
Delete the SUBPAGE_INDEX stuff, but keep __NR_USED_SUBPAGE: now 3.
[hughd@google.com: prefix folio's page_1 and page_2 with double underscore,
give folio's _flags_2 and _head_2 a line documentation each]
Link: https://lkml.kernel.org/r/9e2cb6b-5b58-d3f2-b5ee-5f8a14e8f10@google.com
Link: https://lkml.kernel.org/r/5f52de70-975-e94f-f141-543765736181@google.com
Link: https://lkml.kernel.org/r/3818cc9a-9999-d064-d778-9c94c5911e6@google.com
Signed-off-by: Hugh Dickins <hughd@google.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: James Houghton <jthoughton@google.com>
Cc: John Hubbard <jhubbard@nvidia.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Mina Almasry <almasrymina@google.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Naoya Horiguchi <naoya.horiguchi@linux.dev>
Cc: Peter Xu <peterx@redhat.com>
Cc: Sidhartha Kumar <sidhartha.kumar@oracle.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Yang Shi <shy828301@gmail.com>
Cc: Zach O'Keefe <zokeefe@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-11-03 04:48:45 +03:00
|
|
|
if (rsvd)
|
|
|
|
|
return folio->_hugetlb_cgroup_rsvd;
|
|
|
|
|
else
|
|
|
|
|
return folio->_hugetlb_cgroup;
|
2020-04-02 07:11:15 +03:00
|
|
|
}
|
|
|
|
|
|
2022-11-02 01:30:52 +03:00
|
|
|
static inline struct hugetlb_cgroup *hugetlb_cgroup_from_folio(struct folio *folio)
|
2020-04-02 07:11:15 +03:00
|
|
|
{
|
2022-11-02 01:30:52 +03:00
|
|
|
return __hugetlb_cgroup_from_folio(folio, false);
|
2012-08-01 03:42:15 +04:00
|
|
|
}
|
|
|
|
|
|
2020-04-02 07:11:15 +03:00
|
|
|
static inline struct hugetlb_cgroup *
|
2022-11-02 01:30:52 +03:00
|
|
|
hugetlb_cgroup_from_folio_rsvd(struct folio *folio)
|
2020-04-02 07:11:15 +03:00
|
|
|
{
|
2022-11-02 01:30:52 +03:00
|
|
|
return __hugetlb_cgroup_from_folio(folio, true);
|
2020-04-02 07:11:15 +03:00
|
|
|
}
|
|
|
|
|
|
2022-11-02 01:30:51 +03:00
|
|
|
static inline void __set_hugetlb_cgroup(struct folio *folio,
|
2020-04-02 07:11:15 +03:00
|
|
|
struct hugetlb_cgroup *h_cg, bool rsvd)
|
2012-08-01 03:42:15 +04:00
|
|
|
{
|
2022-11-02 01:30:51 +03:00
|
|
|
VM_BUG_ON_FOLIO(!folio_test_hugetlb(folio), folio);
|
|
|
|
|
if (folio_order(folio) < HUGETLB_CGROUP_MIN_ORDER)
|
2022-07-29 11:01:04 +03:00
|
|
|
return;
|
2020-04-02 07:11:15 +03:00
|
|
|
if (rsvd)
|
mm,hugetlb: use folio fields in second tail page
Patch series "mm,huge,rmap: unify and speed up compound mapcounts".
This patch (of 3):
We want to declare one more int in the first tail of a compound page: that
first tail page being valuable property, since every compound page has a
first tail, but perhaps no more than that.
No problem on 64-bit: there is already space for it. No problem with
32-bit THPs: 5.18 commit 5232c63f46fd ("mm: Make compound_pincount always
available") kindly cleared the space for it, apparently not realizing that
only 64-bit architectures enable CONFIG_THP_SWAP (whose use of tail
page->private might conflict) - but make sure of that in its Kconfig.
But hugetlb pages use tail page->private of the first tail page for a
subpool pointer, which will conflict; and they also use page->private of
the 2nd, 3rd and 4th tails.
Undo "mm: add private field of first tail to struct page and struct
folio"'s recent addition of private_1 to the folio tail: instead add
hugetlb_subpool, hugetlb_cgroup, hugetlb_cgroup_rsvd, hugetlb_hwpoison to
a second tail page of the folio: THP has long been using several fields of
that tail, so make better use of it for hugetlb too. This is not how a
generic folio should be declared in future, but it is an effective
transitional way to make use of it.
Delete the SUBPAGE_INDEX stuff, but keep __NR_USED_SUBPAGE: now 3.
[hughd@google.com: prefix folio's page_1 and page_2 with double underscore,
give folio's _flags_2 and _head_2 a line documentation each]
Link: https://lkml.kernel.org/r/9e2cb6b-5b58-d3f2-b5ee-5f8a14e8f10@google.com
Link: https://lkml.kernel.org/r/5f52de70-975-e94f-f141-543765736181@google.com
Link: https://lkml.kernel.org/r/3818cc9a-9999-d064-d778-9c94c5911e6@google.com
Signed-off-by: Hugh Dickins <hughd@google.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: James Houghton <jthoughton@google.com>
Cc: John Hubbard <jhubbard@nvidia.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Mina Almasry <almasrymina@google.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Naoya Horiguchi <naoya.horiguchi@linux.dev>
Cc: Peter Xu <peterx@redhat.com>
Cc: Sidhartha Kumar <sidhartha.kumar@oracle.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Yang Shi <shy828301@gmail.com>
Cc: Zach O'Keefe <zokeefe@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-11-03 04:48:45 +03:00
|
|
|
folio->_hugetlb_cgroup_rsvd = h_cg;
|
2020-04-02 07:11:15 +03:00
|
|
|
else
|
mm,hugetlb: use folio fields in second tail page
Patch series "mm,huge,rmap: unify and speed up compound mapcounts".
This patch (of 3):
We want to declare one more int in the first tail of a compound page: that
first tail page being valuable property, since every compound page has a
first tail, but perhaps no more than that.
No problem on 64-bit: there is already space for it. No problem with
32-bit THPs: 5.18 commit 5232c63f46fd ("mm: Make compound_pincount always
available") kindly cleared the space for it, apparently not realizing that
only 64-bit architectures enable CONFIG_THP_SWAP (whose use of tail
page->private might conflict) - but make sure of that in its Kconfig.
But hugetlb pages use tail page->private of the first tail page for a
subpool pointer, which will conflict; and they also use page->private of
the 2nd, 3rd and 4th tails.
Undo "mm: add private field of first tail to struct page and struct
folio"'s recent addition of private_1 to the folio tail: instead add
hugetlb_subpool, hugetlb_cgroup, hugetlb_cgroup_rsvd, hugetlb_hwpoison to
a second tail page of the folio: THP has long been using several fields of
that tail, so make better use of it for hugetlb too. This is not how a
generic folio should be declared in future, but it is an effective
transitional way to make use of it.
Delete the SUBPAGE_INDEX stuff, but keep __NR_USED_SUBPAGE: now 3.
[hughd@google.com: prefix folio's page_1 and page_2 with double underscore,
give folio's _flags_2 and _head_2 a line documentation each]
Link: https://lkml.kernel.org/r/9e2cb6b-5b58-d3f2-b5ee-5f8a14e8f10@google.com
Link: https://lkml.kernel.org/r/5f52de70-975-e94f-f141-543765736181@google.com
Link: https://lkml.kernel.org/r/3818cc9a-9999-d064-d778-9c94c5911e6@google.com
Signed-off-by: Hugh Dickins <hughd@google.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: James Houghton <jthoughton@google.com>
Cc: John Hubbard <jhubbard@nvidia.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Mina Almasry <almasrymina@google.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Naoya Horiguchi <naoya.horiguchi@linux.dev>
Cc: Peter Xu <peterx@redhat.com>
Cc: Sidhartha Kumar <sidhartha.kumar@oracle.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Yang Shi <shy828301@gmail.com>
Cc: Zach O'Keefe <zokeefe@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-11-03 04:48:45 +03:00
|
|
|
folio->_hugetlb_cgroup = h_cg;
|
2012-08-01 03:42:15 +04:00
|
|
|
}
|
|
|
|
|
|
2022-11-02 01:30:53 +03:00
|
|
|
static inline void set_hugetlb_cgroup(struct folio *folio,
|
2020-04-02 07:11:15 +03:00
|
|
|
struct hugetlb_cgroup *h_cg)
|
|
|
|
|
{
|
2022-11-02 01:30:53 +03:00
|
|
|
__set_hugetlb_cgroup(folio, h_cg, false);
|
2020-04-02 07:11:15 +03:00
|
|
|
}
|
|
|
|
|
|
2022-11-02 01:30:53 +03:00
|
|
|
static inline void set_hugetlb_cgroup_rsvd(struct folio *folio,
|
2020-04-02 07:11:15 +03:00
|
|
|
struct hugetlb_cgroup *h_cg)
|
|
|
|
|
{
|
2022-11-02 01:30:53 +03:00
|
|
|
__set_hugetlb_cgroup(folio, h_cg, true);
|
2020-04-02 07:11:15 +03:00
|
|
|
}
|
|
|
|
|
|
2012-08-01 03:42:12 +04:00
|
|
|
static inline bool hugetlb_cgroup_disabled(void)
|
|
|
|
|
{
|
2015-09-18 18:56:28 +03:00
|
|
|
return !cgroup_subsys_enabled(hugetlb_cgrp_subsys);
|
2012-08-01 03:42:12 +04:00
|
|
|
}
|
|
|
|
|
|
hugetlb_cgroup: fix imbalanced css_get and css_put pair for shared mappings
The current implementation of hugetlb_cgroup for shared mappings could
have different behavior. Consider the following two scenarios:
1.Assume initial css reference count of hugetlb_cgroup is 1:
1.1 Call hugetlb_reserve_pages with from = 1, to = 2. So css reference
count is 2 associated with 1 file_region.
1.2 Call hugetlb_reserve_pages with from = 2, to = 3. So css reference
count is 3 associated with 2 file_region.
1.3 coalesce_file_region will coalesce these two file_regions into
one. So css reference count is 3 associated with 1 file_region
now.
2.Assume initial css reference count of hugetlb_cgroup is 1 again:
2.1 Call hugetlb_reserve_pages with from = 1, to = 3. So css reference
count is 2 associated with 1 file_region.
Therefore, we might have one file_region while holding one or more css
reference counts. This inconsistency could lead to imbalanced css_get()
and css_put() pair. If we do css_put one by one (i.g. hole punch case),
scenario 2 would put one more css reference. If we do css_put all
together (i.g. truncate case), scenario 1 will leak one css reference.
The imbalanced css_get() and css_put() pair would result in a non-zero
reference when we try to destroy the hugetlb cgroup. The hugetlb cgroup
directory is removed __but__ associated resource is not freed. This
might result in OOM or can not create a new hugetlb cgroup in a busy
workload ultimately.
In order to fix this, we have to make sure that one file_region must
hold exactly one css reference. So in coalesce_file_region case, we
should release one css reference before coalescence. Also only put css
reference when the entire file_region is removed.
The last thing to note is that the caller of region_add() will only hold
one reference to h_cg->css for the whole contiguous reservation region.
But this area might be scattered when there are already some
file_regions reside in it. As a result, many file_regions may share only
one h_cg->css reference. In order to ensure that one file_region must
hold exactly one css reference, we should do css_get() for each
file_region and release the reference held by caller when they are done.
[linmiaohe@huawei.com: fix imbalanced css_get and css_put pair for shared mappings]
Link: https://lkml.kernel.org/r/20210316023002.53921-1-linmiaohe@huawei.com
Link: https://lkml.kernel.org/r/20210301120540.37076-1-linmiaohe@huawei.com
Fixes: 075a61d07a8e ("hugetlb_cgroup: add accounting for shared mappings")
Reported-by: kernel test robot <lkp@intel.com> (auto build test ERROR)
Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Cc: Wanpeng Li <liwp.linux@gmail.com>
Cc: Mina Almasry <almasrymina@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-03-25 07:37:17 +03:00
|
|
|
static inline void hugetlb_cgroup_put_rsvd_cgroup(struct hugetlb_cgroup *h_cg)
|
|
|
|
|
{
|
|
|
|
|
css_put(&h_cg->css);
|
|
|
|
|
}
|
|
|
|
|
|
2021-09-03 00:58:53 +03:00
|
|
|
static inline void resv_map_dup_hugetlb_cgroup_uncharge_info(
|
|
|
|
|
struct resv_map *resv_map)
|
|
|
|
|
{
|
|
|
|
|
if (resv_map->css)
|
|
|
|
|
css_get(resv_map->css);
|
|
|
|
|
}
|
|
|
|
|
|
2021-11-20 03:43:40 +03:00
|
|
|
static inline void resv_map_put_hugetlb_cgroup_uncharge_info(
|
|
|
|
|
struct resv_map *resv_map)
|
|
|
|
|
{
|
|
|
|
|
if (resv_map->css)
|
|
|
|
|
css_put(resv_map->css);
|
|
|
|
|
}
|
|
|
|
|
|
2012-08-01 03:42:18 +04:00
|
|
|
extern int hugetlb_cgroup_charge_cgroup(int idx, unsigned long nr_pages,
|
|
|
|
|
struct hugetlb_cgroup **ptr);
|
2020-04-02 07:11:15 +03:00
|
|
|
extern int hugetlb_cgroup_charge_cgroup_rsvd(int idx, unsigned long nr_pages,
|
|
|
|
|
struct hugetlb_cgroup **ptr);
|
2012-08-01 03:42:18 +04:00
|
|
|
extern void hugetlb_cgroup_commit_charge(int idx, unsigned long nr_pages,
|
|
|
|
|
struct hugetlb_cgroup *h_cg,
|
|
|
|
|
struct page *page);
|
2020-04-02 07:11:15 +03:00
|
|
|
extern void hugetlb_cgroup_commit_charge_rsvd(int idx, unsigned long nr_pages,
|
|
|
|
|
struct hugetlb_cgroup *h_cg,
|
|
|
|
|
struct page *page);
|
2022-11-02 01:30:57 +03:00
|
|
|
extern void hugetlb_cgroup_uncharge_folio(int idx, unsigned long nr_pages,
|
|
|
|
|
struct folio *folio);
|
|
|
|
|
extern void hugetlb_cgroup_uncharge_folio_rsvd(int idx, unsigned long nr_pages,
|
|
|
|
|
struct folio *folio);
|
2020-04-02 07:11:15 +03:00
|
|
|
|
2012-08-01 03:42:18 +04:00
|
|
|
extern void hugetlb_cgroup_uncharge_cgroup(int idx, unsigned long nr_pages,
|
|
|
|
|
struct hugetlb_cgroup *h_cg);
|
2020-04-02 07:11:15 +03:00
|
|
|
extern void hugetlb_cgroup_uncharge_cgroup_rsvd(int idx, unsigned long nr_pages,
|
|
|
|
|
struct hugetlb_cgroup *h_cg);
|
2020-04-02 07:11:21 +03:00
|
|
|
extern void hugetlb_cgroup_uncharge_counter(struct resv_map *resv,
|
|
|
|
|
unsigned long start,
|
|
|
|
|
unsigned long end);
|
2020-04-02 07:11:15 +03:00
|
|
|
|
hugetlb_cgroup: add accounting for shared mappings
For shared mappings, the pointer to the hugetlb_cgroup to uncharge lives
in the resv_map entries, in file_region->reservation_counter.
After a call to region_chg, we charge the approprate hugetlb_cgroup, and
if successful, we pass on the hugetlb_cgroup info to a follow up
region_add call. When a file_region entry is added to the resv_map via
region_add, we put the pointer to that cgroup in
file_region->reservation_counter. If charging doesn't succeed, we report
the error to the caller, so that the kernel fails the reservation.
On region_del, which is when the hugetlb memory is unreserved, we also
uncharge the file_region->reservation_counter.
[akpm@linux-foundation.org: forward declare struct file_region]
Signed-off-by: Mina Almasry <almasrymina@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Sandipan Das <sandipan@linux.ibm.com>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Shuah Khan <shuah@kernel.org>
Link: http://lkml.kernel.org/r/20200211213128.73302-5-almasrymina@google.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-04-02 07:11:28 +03:00
|
|
|
extern void hugetlb_cgroup_uncharge_file_region(struct resv_map *resv,
|
|
|
|
|
struct file_region *rg,
|
hugetlb_cgroup: fix imbalanced css_get and css_put pair for shared mappings
The current implementation of hugetlb_cgroup for shared mappings could
have different behavior. Consider the following two scenarios:
1.Assume initial css reference count of hugetlb_cgroup is 1:
1.1 Call hugetlb_reserve_pages with from = 1, to = 2. So css reference
count is 2 associated with 1 file_region.
1.2 Call hugetlb_reserve_pages with from = 2, to = 3. So css reference
count is 3 associated with 2 file_region.
1.3 coalesce_file_region will coalesce these two file_regions into
one. So css reference count is 3 associated with 1 file_region
now.
2.Assume initial css reference count of hugetlb_cgroup is 1 again:
2.1 Call hugetlb_reserve_pages with from = 1, to = 3. So css reference
count is 2 associated with 1 file_region.
Therefore, we might have one file_region while holding one or more css
reference counts. This inconsistency could lead to imbalanced css_get()
and css_put() pair. If we do css_put one by one (i.g. hole punch case),
scenario 2 would put one more css reference. If we do css_put all
together (i.g. truncate case), scenario 1 will leak one css reference.
The imbalanced css_get() and css_put() pair would result in a non-zero
reference when we try to destroy the hugetlb cgroup. The hugetlb cgroup
directory is removed __but__ associated resource is not freed. This
might result in OOM or can not create a new hugetlb cgroup in a busy
workload ultimately.
In order to fix this, we have to make sure that one file_region must
hold exactly one css reference. So in coalesce_file_region case, we
should release one css reference before coalescence. Also only put css
reference when the entire file_region is removed.
The last thing to note is that the caller of region_add() will only hold
one reference to h_cg->css for the whole contiguous reservation region.
But this area might be scattered when there are already some
file_regions reside in it. As a result, many file_regions may share only
one h_cg->css reference. In order to ensure that one file_region must
hold exactly one css reference, we should do css_get() for each
file_region and release the reference held by caller when they are done.
[linmiaohe@huawei.com: fix imbalanced css_get and css_put pair for shared mappings]
Link: https://lkml.kernel.org/r/20210316023002.53921-1-linmiaohe@huawei.com
Link: https://lkml.kernel.org/r/20210301120540.37076-1-linmiaohe@huawei.com
Fixes: 075a61d07a8e ("hugetlb_cgroup: add accounting for shared mappings")
Reported-by: kernel test robot <lkp@intel.com> (auto build test ERROR)
Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Cc: Wanpeng Li <liwp.linux@gmail.com>
Cc: Mina Almasry <almasrymina@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-03-25 07:37:17 +03:00
|
|
|
unsigned long nr_pages,
|
|
|
|
|
bool region_del);
|
hugetlb_cgroup: add accounting for shared mappings
For shared mappings, the pointer to the hugetlb_cgroup to uncharge lives
in the resv_map entries, in file_region->reservation_counter.
After a call to region_chg, we charge the approprate hugetlb_cgroup, and
if successful, we pass on the hugetlb_cgroup info to a follow up
region_add call. When a file_region entry is added to the resv_map via
region_add, we put the pointer to that cgroup in
file_region->reservation_counter. If charging doesn't succeed, we report
the error to the caller, so that the kernel fails the reservation.
On region_del, which is when the hugetlb memory is unreserved, we also
uncharge the file_region->reservation_counter.
[akpm@linux-foundation.org: forward declare struct file_region]
Signed-off-by: Mina Almasry <almasrymina@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Sandipan Das <sandipan@linux.ibm.com>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Shuah Khan <shuah@kernel.org>
Link: http://lkml.kernel.org/r/20200211213128.73302-5-almasrymina@google.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-04-02 07:11:28 +03:00
|
|
|
|
2012-12-19 02:23:19 +04:00
|
|
|
extern void hugetlb_cgroup_file_init(void) __init;
|
2022-11-02 01:30:54 +03:00
|
|
|
extern void hugetlb_cgroup_migrate(struct folio *old_folio,
|
|
|
|
|
struct folio *new_folio);
|
2012-08-01 03:42:18 +04:00
|
|
|
|
2012-08-01 03:42:12 +04:00
|
|
|
#else
|
hugetlb_cgroup: add accounting for shared mappings
For shared mappings, the pointer to the hugetlb_cgroup to uncharge lives
in the resv_map entries, in file_region->reservation_counter.
After a call to region_chg, we charge the approprate hugetlb_cgroup, and
if successful, we pass on the hugetlb_cgroup info to a follow up
region_add call. When a file_region entry is added to the resv_map via
region_add, we put the pointer to that cgroup in
file_region->reservation_counter. If charging doesn't succeed, we report
the error to the caller, so that the kernel fails the reservation.
On region_del, which is when the hugetlb memory is unreserved, we also
uncharge the file_region->reservation_counter.
[akpm@linux-foundation.org: forward declare struct file_region]
Signed-off-by: Mina Almasry <almasrymina@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Sandipan Das <sandipan@linux.ibm.com>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Shuah Khan <shuah@kernel.org>
Link: http://lkml.kernel.org/r/20200211213128.73302-5-almasrymina@google.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-04-02 07:11:28 +03:00
|
|
|
static inline void hugetlb_cgroup_uncharge_file_region(struct resv_map *resv,
|
|
|
|
|
struct file_region *rg,
|
hugetlb_cgroup: fix imbalanced css_get and css_put pair for shared mappings
The current implementation of hugetlb_cgroup for shared mappings could
have different behavior. Consider the following two scenarios:
1.Assume initial css reference count of hugetlb_cgroup is 1:
1.1 Call hugetlb_reserve_pages with from = 1, to = 2. So css reference
count is 2 associated with 1 file_region.
1.2 Call hugetlb_reserve_pages with from = 2, to = 3. So css reference
count is 3 associated with 2 file_region.
1.3 coalesce_file_region will coalesce these two file_regions into
one. So css reference count is 3 associated with 1 file_region
now.
2.Assume initial css reference count of hugetlb_cgroup is 1 again:
2.1 Call hugetlb_reserve_pages with from = 1, to = 3. So css reference
count is 2 associated with 1 file_region.
Therefore, we might have one file_region while holding one or more css
reference counts. This inconsistency could lead to imbalanced css_get()
and css_put() pair. If we do css_put one by one (i.g. hole punch case),
scenario 2 would put one more css reference. If we do css_put all
together (i.g. truncate case), scenario 1 will leak one css reference.
The imbalanced css_get() and css_put() pair would result in a non-zero
reference when we try to destroy the hugetlb cgroup. The hugetlb cgroup
directory is removed __but__ associated resource is not freed. This
might result in OOM or can not create a new hugetlb cgroup in a busy
workload ultimately.
In order to fix this, we have to make sure that one file_region must
hold exactly one css reference. So in coalesce_file_region case, we
should release one css reference before coalescence. Also only put css
reference when the entire file_region is removed.
The last thing to note is that the caller of region_add() will only hold
one reference to h_cg->css for the whole contiguous reservation region.
But this area might be scattered when there are already some
file_regions reside in it. As a result, many file_regions may share only
one h_cg->css reference. In order to ensure that one file_region must
hold exactly one css reference, we should do css_get() for each
file_region and release the reference held by caller when they are done.
[linmiaohe@huawei.com: fix imbalanced css_get and css_put pair for shared mappings]
Link: https://lkml.kernel.org/r/20210316023002.53921-1-linmiaohe@huawei.com
Link: https://lkml.kernel.org/r/20210301120540.37076-1-linmiaohe@huawei.com
Fixes: 075a61d07a8e ("hugetlb_cgroup: add accounting for shared mappings")
Reported-by: kernel test robot <lkp@intel.com> (auto build test ERROR)
Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Cc: Wanpeng Li <liwp.linux@gmail.com>
Cc: Mina Almasry <almasrymina@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-03-25 07:37:17 +03:00
|
|
|
unsigned long nr_pages,
|
|
|
|
|
bool region_del)
|
hugetlb_cgroup: add accounting for shared mappings
For shared mappings, the pointer to the hugetlb_cgroup to uncharge lives
in the resv_map entries, in file_region->reservation_counter.
After a call to region_chg, we charge the approprate hugetlb_cgroup, and
if successful, we pass on the hugetlb_cgroup info to a follow up
region_add call. When a file_region entry is added to the resv_map via
region_add, we put the pointer to that cgroup in
file_region->reservation_counter. If charging doesn't succeed, we report
the error to the caller, so that the kernel fails the reservation.
On region_del, which is when the hugetlb memory is unreserved, we also
uncharge the file_region->reservation_counter.
[akpm@linux-foundation.org: forward declare struct file_region]
Signed-off-by: Mina Almasry <almasrymina@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Sandipan Das <sandipan@linux.ibm.com>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Shuah Khan <shuah@kernel.org>
Link: http://lkml.kernel.org/r/20200211213128.73302-5-almasrymina@google.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-04-02 07:11:28 +03:00
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2022-11-02 01:30:52 +03:00
|
|
|
static inline struct hugetlb_cgroup *hugetlb_cgroup_from_folio(struct folio *folio)
|
2020-04-02 07:11:15 +03:00
|
|
|
{
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline struct hugetlb_cgroup *
|
2022-11-02 01:30:52 +03:00
|
|
|
hugetlb_cgroup_from_folio_rsvd(struct folio *folio)
|
2020-04-02 07:11:15 +03:00
|
|
|
{
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2022-11-02 01:30:53 +03:00
|
|
|
static inline void set_hugetlb_cgroup(struct folio *folio,
|
2020-04-02 07:11:15 +03:00
|
|
|
struct hugetlb_cgroup *h_cg)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2022-11-02 01:30:53 +03:00
|
|
|
static inline void set_hugetlb_cgroup_rsvd(struct folio *folio,
|
2020-04-02 07:11:15 +03:00
|
|
|
struct hugetlb_cgroup *h_cg)
|
2012-08-01 03:42:15 +04:00
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2012-08-01 03:42:12 +04:00
|
|
|
static inline bool hugetlb_cgroup_disabled(void)
|
|
|
|
|
{
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
hugetlb_cgroup: fix imbalanced css_get and css_put pair for shared mappings
The current implementation of hugetlb_cgroup for shared mappings could
have different behavior. Consider the following two scenarios:
1.Assume initial css reference count of hugetlb_cgroup is 1:
1.1 Call hugetlb_reserve_pages with from = 1, to = 2. So css reference
count is 2 associated with 1 file_region.
1.2 Call hugetlb_reserve_pages with from = 2, to = 3. So css reference
count is 3 associated with 2 file_region.
1.3 coalesce_file_region will coalesce these two file_regions into
one. So css reference count is 3 associated with 1 file_region
now.
2.Assume initial css reference count of hugetlb_cgroup is 1 again:
2.1 Call hugetlb_reserve_pages with from = 1, to = 3. So css reference
count is 2 associated with 1 file_region.
Therefore, we might have one file_region while holding one or more css
reference counts. This inconsistency could lead to imbalanced css_get()
and css_put() pair. If we do css_put one by one (i.g. hole punch case),
scenario 2 would put one more css reference. If we do css_put all
together (i.g. truncate case), scenario 1 will leak one css reference.
The imbalanced css_get() and css_put() pair would result in a non-zero
reference when we try to destroy the hugetlb cgroup. The hugetlb cgroup
directory is removed __but__ associated resource is not freed. This
might result in OOM or can not create a new hugetlb cgroup in a busy
workload ultimately.
In order to fix this, we have to make sure that one file_region must
hold exactly one css reference. So in coalesce_file_region case, we
should release one css reference before coalescence. Also only put css
reference when the entire file_region is removed.
The last thing to note is that the caller of region_add() will only hold
one reference to h_cg->css for the whole contiguous reservation region.
But this area might be scattered when there are already some
file_regions reside in it. As a result, many file_regions may share only
one h_cg->css reference. In order to ensure that one file_region must
hold exactly one css reference, we should do css_get() for each
file_region and release the reference held by caller when they are done.
[linmiaohe@huawei.com: fix imbalanced css_get and css_put pair for shared mappings]
Link: https://lkml.kernel.org/r/20210316023002.53921-1-linmiaohe@huawei.com
Link: https://lkml.kernel.org/r/20210301120540.37076-1-linmiaohe@huawei.com
Fixes: 075a61d07a8e ("hugetlb_cgroup: add accounting for shared mappings")
Reported-by: kernel test robot <lkp@intel.com> (auto build test ERROR)
Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Cc: Wanpeng Li <liwp.linux@gmail.com>
Cc: Mina Almasry <almasrymina@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-03-25 07:37:17 +03:00
|
|
|
static inline void hugetlb_cgroup_put_rsvd_cgroup(struct hugetlb_cgroup *h_cg)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2021-09-03 00:58:53 +03:00
|
|
|
static inline void resv_map_dup_hugetlb_cgroup_uncharge_info(
|
|
|
|
|
struct resv_map *resv_map)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2021-11-20 03:43:40 +03:00
|
|
|
static inline void resv_map_put_hugetlb_cgroup_uncharge_info(
|
|
|
|
|
struct resv_map *resv_map)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2020-04-02 07:11:15 +03:00
|
|
|
static inline int hugetlb_cgroup_charge_cgroup(int idx, unsigned long nr_pages,
|
|
|
|
|
struct hugetlb_cgroup **ptr)
|
2012-08-01 03:42:18 +04:00
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2020-04-02 07:11:15 +03:00
|
|
|
static inline int hugetlb_cgroup_charge_cgroup_rsvd(int idx,
|
|
|
|
|
unsigned long nr_pages,
|
|
|
|
|
struct hugetlb_cgroup **ptr)
|
|
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void hugetlb_cgroup_commit_charge(int idx, unsigned long nr_pages,
|
|
|
|
|
struct hugetlb_cgroup *h_cg,
|
|
|
|
|
struct page *page)
|
2012-08-01 03:42:18 +04:00
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void
|
2020-04-02 07:11:15 +03:00
|
|
|
hugetlb_cgroup_commit_charge_rsvd(int idx, unsigned long nr_pages,
|
|
|
|
|
struct hugetlb_cgroup *h_cg,
|
|
|
|
|
struct page *page)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2022-11-02 01:30:57 +03:00
|
|
|
static inline void hugetlb_cgroup_uncharge_folio(int idx, unsigned long nr_pages,
|
|
|
|
|
struct folio *folio)
|
2020-04-02 07:11:15 +03:00
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2022-11-02 01:30:57 +03:00
|
|
|
static inline void hugetlb_cgroup_uncharge_folio_rsvd(int idx,
|
2020-04-02 07:11:15 +03:00
|
|
|
unsigned long nr_pages,
|
2022-11-02 01:30:57 +03:00
|
|
|
struct folio *folio)
|
2020-04-02 07:11:15 +03:00
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
static inline void hugetlb_cgroup_uncharge_cgroup(int idx,
|
|
|
|
|
unsigned long nr_pages,
|
|
|
|
|
struct hugetlb_cgroup *h_cg)
|
2012-08-01 03:42:18 +04:00
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void
|
2020-04-02 07:11:15 +03:00
|
|
|
hugetlb_cgroup_uncharge_cgroup_rsvd(int idx, unsigned long nr_pages,
|
|
|
|
|
struct hugetlb_cgroup *h_cg)
|
2012-08-01 03:42:18 +04:00
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2020-04-02 07:11:21 +03:00
|
|
|
static inline void hugetlb_cgroup_uncharge_counter(struct resv_map *resv,
|
|
|
|
|
unsigned long start,
|
|
|
|
|
unsigned long end)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2012-12-19 02:23:19 +04:00
|
|
|
static inline void hugetlb_cgroup_file_init(void)
|
2012-08-01 03:42:24 +04:00
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2022-11-02 01:30:54 +03:00
|
|
|
static inline void hugetlb_cgroup_migrate(struct folio *old_folio,
|
|
|
|
|
struct folio *new_folio)
|
2012-08-01 03:42:27 +04:00
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2012-08-01 03:42:12 +04:00
|
|
|
#endif /* CONFIG_MEM_RES_CTLR_HUGETLB */
|
|
|
|
|
#endif
|
