On Thu, Jan 4, 2024 at 1:44 PM Jakub Kicinski wrote:
>
> On Thu, 21 Dec 2023 15:44:22 -0800 Mina Almasry wrote:
> > The warning is like so:
> >
> > ./include/net/page_pool/helpers.h: In function ‘page_pool_alloc’:
> > ./include/linux/stddef.h:8:14: warning: returnin
Minor fix for virtio: code wanting to access the fields inside an skb
frag should use the skb_frag_*() helpers, instead of accessing the
fields directly. This allows for extensions where the underlying
memory is not a page.
Acked-by: Stefano Garzarella
Signed-off-by: Mina Almasry
---
v3
On Thu, Dec 21, 2023 at 3:23 PM Shakeel Butt wrote:
>
> On Wed, Dec 20, 2023 at 01:45:01PM -0800, Mina Almasry wrote:
> > Add the netmem_ref type, an abstraction for network memory.
> >
> > To add support for new memory types to the net stack, we must first
> > ab
a debug assert that the skb frag is
indeed backed by a page, and do a cast.
Add skb[_frag]_fill_netmem_*() and skb_add_rx_frag_netmem() helpers so
that the API can be used to create netmem skbs.
Signed-off-by: Mina Almasry
---
v3;
- Renamed the fields in skb_frag_t.
v2:
- Add skb frag filling
underneath. In
parallel there is an undergoing effort to add support for devmem to the
net stack:
https://lore.kernel.org/netdev/20231208005250.2910004-1-almasrym...@google.com/
Signed-off-by: Mina Almasry
---
v3:
- Modify struct netmem from a union of struct page + new types to an opaque
Minor fix for virtio: code wanting to access the fields inside an skb
frag should use the skb_frag_*() helpers, instead of accessing the
fields directly. This allows for extensions where the underlying
memory is not a page.
Signed-off-by: Mina Almasry
---
v2:
- Also fix skb_frag_off
Cc: Willem de Bruijn
Mina Almasry (3):
vsock/virtio: use skb_frag_*() helpers
net: introduce abstraction for network memory
net: add netmem_ref to skb_frag_t
include/linux/skbuff.h | 92 ++--
include/net/netmem.h | 41 ++
net
On Mon, Dec 18, 2023 at 4:39 AM Yunsheng Lin wrote:
>
> On 2023/12/17 16:09, Mina Almasry wrote:
> > Use netmem_t instead of page directly in skb_frag_t. Currently netmem_t
> > is always a struct page underneath, but the abstraction allows efforts
> > to add support
, add a debug assert that the skb frag is
indeed backed by a page, and do a cast.
Add skb[_frag]_fill_netmem_*() and skb_add_rx_frag_netmem() helpers so
that the API can be used to create netmem skbs.
Signed-off-by: Mina Almasry
---
v2:
- Add skb frag filling helpers.
---
include/linux/skbuff.h
a struct page underneath. In
parallel there is an undergoing effort to add support for devmem to the
net stack:
https://lore.kernel.org/netdev/20231208005250.2910004-1-almasrym...@google.com/
Signed-off-by: Mina Almasry
---
v2:
- Use container_of instead of a type cast (David).
---
include
Minor fix for virtio: code wanting to access the fields inside an skb
frag should use the skb_frag_*() helpers, instead of accessing the
fields directly. This allows for extensions where the underlying
memory is not a page.
Signed-off-by: Mina Almasry
---
v2:
- Also fix skb_frag_off
...@google.com/
Cc: Jason Gunthorpe
Cc: Christian König
Cc: Shakeel Butt
Cc: Yunsheng Lin
Cc: Willem de Bruijn
Mina Almasry (3):
vsock/virtio: use skb_frag_*() helpers
net: introduce abstraction for network memory
net: add netmem_t to skb_frag_t
include/linux/skbuff.h | 70
f the device. Previously, the target_node was always 0
> > > > > > > since
> > > > > > > the ndr_desc.target_node field was never explicitly set. The code
> > > > > > > for
> > > > > > > computing the numa node is taken from cxl_pmem
the ndr_desc.target_node field was never explicitly set. The code for
> > > > > computing the numa node is taken from cxl_pmem_region_probe in
> > > > > drivers/cxl/pmem.c.
> > > > >
> > > > > Signed-off-by: Michael Sammler
Tested-by: Mina
rg->to - f);
> > +
> > + del += rg->to - f;
> > + rg->to = f;
> > }
> > }
> >
> > @@ -2454,6 +2453,9 @@ struct page *alloc_huge_page(struct vm_area_struct
> > *vma,
> >
> > rsv_adjust = hugepage_subpool_put_pages(spool, 1);
> > hugetlb_acct_memory(h, -rsv_adjust);
> > + if (deferred_reserve)
> > + hugetlb_cgroup_uncharge_page_rsvd(hstate_index(h),
> > + pages_per_huge_page(h), page);
> > }
> > return page;
> >
> > --
> > 2.25.4
>
Sorry for the late review. Looks good to me.
Reviewed-by: Mina Almasry
On Wed, Oct 14, 2020 at 9:15 AM David Hildenbrand wrote:
>
> On 14.10.20 17:22, David Hildenbrand wrote:
> > Hi everybody,
> >
> > Michal Privoznik played with "free page reporting" in QEMU/virtio-balloon
> > with hugetlbfs and reported that this results in [1]
> >
> > 1. WARNING: CPU: 13 PID:
On Sat, May 16, 2020 at 5:12 PM John Hubbard wrote:
>
> Remove unused variable "i", which was triggering a compiler warning.
>
> Fixes: 29750f71a9b4 ("hugetlb_cgroup: add hugetlb_cgroup reservation tests")
> Cc: Mina Almasry
> Signed-off-by: John Hubbar
On Mon, Oct 21, 2019 at 12:02 PM Mike Kravetz wrote:
>
> On 10/12/19 5:30 PM, Mina Almasry wrote:
> > A follow up patch in this series adds hugetlb cgroup uncharge info the
> > file_region entries in resv->regions. The cgroup uncharge info may
> > differ for dif
On Mon, Oct 14, 2019 at 10:33 AM Mike Kravetz wrote:
>
> On 10/11/19 1:41 PM, Mina Almasry wrote:
> > On Fri, Oct 11, 2019 at 12:10 PM Mina Almasry
> > wrote:
> >>
> >> On Mon, Sep 23, 2019 at 10:47 AM Mike Kravetz
> >> wrote:
> >>>
>
Add docs for how to use hugetlb_cgroup reservations, and their behavior.
Signed-off-by: Mina Almasry
Acked-by: Hillf Danton
---
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
-off-by: Mina Almasry
---
Changes in v6:
- Updates tests for cgroups-v2 and NORESERVE allocations.
---
tools/testing/selftests/vm/.gitignore | 1 +
tools/testing/selftests/vm/Makefile | 1 +
.../selftests/vm/charge_reserved_hugetlb.sh | 527
served, we also uncharge
the file_region->reservation_counter.
Signed-off-by: Mina Almasry
---
mm/hugetlb.c | 147 ---
1 file changed, 116 insertions(+), 31 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index f9c1947925bb9..af336bf227f
Support MAP_NORESERVE accounting as part of the new counter.
For each hugepage allocation, at allocation time we check if there is
a reservation for this allocation or not. If there is a reservation for
this allocation, then this allocation was charged at reservation time,
and we don't re-account
ounter.
On hugetlb_vm_op_close, we uncharge resv_map->reservation_counter.
Signed-off-by: Mina Almasry
Acked-by: Hillf Danton
---
include/linux/hugetlb.h| 8 +++
include/linux/hugetlb_cgroup.h | 11 +
mm/hugetlb.c | 44 +
, and hugetlb_cgroup_css_offline.
Signed-off-by: Mina Almasry
---
include/linux/hugetlb_cgroup.h | 67 +-
mm/hugetlb.c | 17 +++---
mm/hugetlb_cgroup.c| 100 +
3 files changed, 130 insertions(+), 54 deletions
m line 176: Invalid argument
- LD_PRELOAD=libhugetlbfs.so HUGETLB_SHM=yes shmoverride_unlinked (2M: 32):
FAILshmget failed size 2097152 from line 176: Invalid argument
[1]: https://www.kernel.org/doc/html/latest/vm/hugetlbfs_reserv.html
Signed-off-by: Mina Almasry
Acked-by: Hi
---
mm/hugetlb_cgroup.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/mm/hugetlb_cgroup.c b/mm/hugetlb_cgroup.c
index 854117513979b..ac1500205faf7 100644
--- a/mm/hugetlb_cgroup.c
+++ b/mm/hugetlb_cgroup.c
@@ -503,8 +503,13 @@ static void __init
ent adds_in_progress by 1 after region_add or region_abort. Instead,
region_chg calls add_reservation_in_range() to count the number of regions
needed and allocates those, and that info is passed to region_add and
region_abort to decrement adds_in_progress correctly.
Signed-off-by: Mina Almasry
On Fri, Oct 11, 2019 at 12:10 PM Mina Almasry wrote:
>
> On Mon, Sep 23, 2019 at 10:47 AM Mike Kravetz wrote:
> >
> > On 9/19/19 3:24 PM, Mina Almasry wrote:
> > > Patch series implements hugetlb_cgroup reservation usage and limits, which
> > > track huge
On Mon, Sep 23, 2019 at 10:47 AM Mike Kravetz wrote:
>
> On 9/19/19 3:24 PM, Mina Almasry wrote:
> > Patch series implements hugetlb_cgroup reservation usage and limits, which
> > track hugetlb reservations rather than hugetlb memory faulted in. Details of
> > the app
On Fri, Sep 27, 2019 at 2:59 PM Mike Kravetz wrote:
>
> On 9/26/19 5:55 PM, Mina Almasry wrote:
> > Provided we keep the existing controller untouched, should the new
> > controller track:
> >
> > 1. only reservations, or
> > 2. both reservations and allocat
On Fri, Sep 27, 2019 at 2:44 PM Mike Kravetz wrote:
>
> On 9/19/19 3:24 PM, Mina Almasry wrote:
> > A follow up patch in this series adds hugetlb cgroup uncharge info the
> > file_region entries in resv->regions. The cgroup uncharge info may
> > differ for different reg
On Thu, Sep 26, 2019 at 2:23 PM Mike Kravetz wrote:
>
> On 9/26/19 12:28 PM, David Rientjes wrote:
> > On Tue, 24 Sep 2019, Mina Almasry wrote:
> >
> >>> I personally prefer the one counter approach only for the reason that it
> >>> exposes less
On Mon, Sep 23, 2019 at 2:27 PM Mike Kravetz wrote:
>
> On 9/23/19 12:18 PM, Mina Almasry wrote:
> > On Mon, Sep 23, 2019 at 10:47 AM Mike Kravetz
> > wrote:
> >>
> >> On 9/19/19 3:24 PM, Mina Almasry wrote:
> >>> Patch series implements hu
On Mon, Sep 23, 2019 at 10:47 AM Mike Kravetz wrote:
>
> On 9/19/19 3:24 PM, Mina Almasry wrote:
> > Patch series implements hugetlb_cgroup reservation usage and limits, which
> > track hugetlb reservations rather than hugetlb memory faulted in. Details of
> > the app
v2:
- Split the patch into a 5 patch series.
- Fixed patch subject.
Mina Almasry (7):
hugetlb_cgroup: Add hugetlb_cgroup reservation counter
hugetlb_cgroup: add interface for charge/uncharge hugetlb reservations
hugetlb_cgroup: add reservation accounting for private mappings
hugetlb: disa
Add docs for how to use hugetlb_cgroup reservations, and their behavior.
Signed-off-by: Mina Almasry
Acked-by: Hillf Danton
---
.../admin-guide/cgroup-v1/hugetlb.rst | 85 ---
1 file changed, 74 insertions(+), 11 deletions(-)
diff --git a/Documentation/admin-guide
served, we also uncharge
the file_region->reservation_counter.
Signed-off-by: Mina Almasry
---
mm/hugetlb.c | 126 ++-
1 file changed, 105 insertions(+), 21 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index d03b048084a3..ae573eff80
-off-by: Mina Almasry
---
tools/testing/selftests/vm/.gitignore | 1 +
tools/testing/selftests/vm/Makefile | 1 +
.../selftests/vm/charge_reserved_hugetlb.sh | 461 ++
.../selftests/vm/write_hugetlb_memory.sh | 22 +
.../testing/selftests/vm
, and hugetlb_cgroup_css_offline.
Signed-off-by: Mina Almasry
---
include/linux/hugetlb_cgroup.h | 22 ++
mm/hugetlb.c | 6 ++-
mm/hugetlb_cgroup.c| 77 --
3 files changed, 83 insertions(+), 22 deletions(-)
diff --git
ounter.
On hugetlb_vm_op_close, we uncharge resv_map->reservation_counter.
Signed-off-by: Mina Almasry
Acked-by: Hillf Danton
---
include/linux/hugetlb.h| 8 +++
include/linux/hugetlb_cgroup.h | 11 +
mm/hugetlb.c | 44 +
ent adds_in_progress by 1 after region_add or region_abort. Instead,
region_chg calls add_reservation_in_range() to count the number of regions
needed and allocates those, and that info is passed to region_add and
region_abort to decrement adds_in_progress correctly.
Signed-off-
ze 2097152 from line 176: Invalid argument
- LD_PRELOAD=libhugetlbfs.so HUGETLB_SHM=yes shmoverride_unlinked (2M: 32):
FAILshmget failed size 2097152 from line 176: Invalid argument
[1]: https://www.kernel.org/doc/html/latest/vm/hugetlbfs_reserv.html
Signed-off-by: Mina Almasry
Acked
. It should improve maintainability anyway on its own.
Signed-off-by: Mina Almasry
Reviewed-by: Mike Kravetz
---
mm/hugetlb.c | 119 ---
1 file changed, 57 insertions(+), 62 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index a14f6047fc7e
er to reason about and
maintain.
In addition, a follow up patch in another series that disables region
coalescing, which would be further complicated if the race with
region_del exists.
Signed-off-by: Mina Almasry
Reviewed-by: Mike Kravetz
---
mm/hugetlb.c | 63 +-
been already reviewed by Mike as part of the previous series, so
already hold the Reviewed-by tag.
Mina Almasry (2):
hugetlb: region_chg provides only cache entry
hugetlb: remove duplicated code
mm/hugetlb.c | 180 +++
1 file changed, 67
On Mon, Sep 16, 2019 at 6:52 PM shuah wrote:
>
> On 9/10/19 5:31 PM, Mina Almasry wrote:
> > The tests use both shared and private mapped hugetlb memory, and
> > monitors the hugetlb usage counter as well as the hugetlb reservation
> > counter. They test different config
On Mon, Sep 16, 2019 at 4:57 PM Mike Kravetz wrote:
>
> On 9/10/19 4:31 PM, Mina Almasry wrote:
> > A follow up patch in this series adds hugetlb cgroup uncharge info the
> > file_region entries in resv->regions. The cgroup uncharge info may
> > differ for different reg
ounter.
On hugetlb_vm_op_close, we uncharge resv_map->reservation_counter.
Signed-off-by: Mina Almasry
---
include/linux/hugetlb.h| 8 ++
include/linux/hugetlb_cgroup.h | 11
mm/hugetlb.c | 47 --
mm/hugetlb_cgroup.c
, and hugetlb_cgroup_css_offline.
Signed-off-by: Mina Almasry
---
include/linux/hugetlb_cgroup.h | 13 --
mm/hugetlb.c | 6 ++-
mm/hugetlb_cgroup.c| 82 +++---
3 files changed, 80 insertions(+), 21 deletions(-)
diff --git a/include
. It should improve maintainability anyway on its own.
Signed-off-by: Mina Almasry
---
mm/hugetlb.c | 116 ---
1 file changed, 54 insertions(+), 62 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index bea51ae422f63..ce5ed1056fefd 100644
--- a/mm
Add docs for how to use hugetlb_cgroup reservations, and their behavior.
Signed-off-by: Mina Almasry
Acked-by: Hillf Danton
---
.../admin-guide/cgroup-v1/hugetlb.rst | 84 ---
1 file changed, 73 insertions(+), 11 deletions(-)
diff --git a/Documentation/admin-guide
served, we also uncharge
the file_region->reservation_counter.
Signed-off-by: Mina Almasry
---
mm/hugetlb.c | 147 ---
1 file changed, 115 insertions(+), 32 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 5eca34d9b753d..711690b87dc
nt
Signed-off-by: Mina Almasry
[1]: https://www.kernel.org/doc/html/latest/vm/hugetlbfs_reserv.html
Changes in v4:
- Split up 'hugetlb_cgroup: add accounting for shared mappings' into 4 patches
for better isolation and context on the individual changes:
- hugetlb_cgroup: add accounting
-off-by: Mina Almasry
---
tools/testing/selftests/vm/.gitignore | 1 +
tools/testing/selftests/vm/Makefile | 4 +
.../selftests/vm/charge_reserved_hugetlb.sh | 440 ++
.../selftests/vm/write_hugetlb_memory.sh | 22 +
.../testing/selftests/vm
These counters will track hugetlb reservations rather than hugetlb
memory faulted in. This patch only adds the counter, following patches
add the charging and uncharging of the counter.
Signed-off-by: Mina Almasry
Acked-by: Hillf Danton
---
include/linux/hugetlb.h | 16 +-
mm
er to reason about and
maintain.
In addition, a follow up patch in this series disables region
coalescing, which would be further complicated if the race with
region_del exists.
Signed-off-by: Mina Almasry
---
mm/hugetlb.c | 63 +---
1 file changed, 11
ent adds_in_progress by 1 after region_add or region_abort. Instead,
region_chg calls add_reservation_in_range() to count the number of regions
needed and allocates those, and that info is passed to region_add and
region_abort to decrement adds_in_progress correctly.
Signed-off
On Tue, Sep 3, 2019 at 4:46 PM Mike Kravetz wrote:
>
> On 9/3/19 10:57 AM, Mike Kravetz wrote:
> > On 8/29/19 12:18 AM, Michal Hocko wrote:
> >> [Cc cgroups maintainers]
> >>
> >> On Wed 28-08-19 10:58:00, Mina Almasry wrote:
> >>>
On Tue, Sep 3, 2019 at 10:58 AM Mike Kravetz wrote:
>
> On 8/29/19 12:18 AM, Michal Hocko wrote:
> > [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 wrote:
> >>>
>
On Wed, Aug 28, 2019 at 4:23 AM Michal Hocko 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 t
The tests use both shared and private mapped hugetlb memory, and
monitors the hugetlb usage counter as well as the hugetlb reservation
counter. They test different configurations such as hugetlb memory usage
via hugetlbfs, or MAP_HUGETLB, or shmget/shmat, and with and without
MAP_POPULATE.
---
Add docs for how to use hugetlb_cgroup reservations, and their behavior.
---
.../admin-guide/cgroup-v1/hugetlb.rst | 84 ---
1 file changed, 73 insertions(+), 11 deletions(-)
diff --git a/Documentation/admin-guide/cgroup-v1/hugetlb.rst
For shared mappings, the pointer to the hugetlb_cgroup to uncharge lives
in the resv_map entries, in file_region->reservation_counter.
When a file_region entry is added to the resv_map via region_add, we
also charge the appropriate hugetlb_cgroup and put the pointer to that
in
Augements hugetlb_cgroup_charge_cgroup to be able to charge hugetlb
usage or hugetlb reservation counter.
Adds a new interface to uncharge a hugetlb_cgroup counter via
hugetlb_cgroup_uncharge_counter.
Integrates the counter with hugetlb_cgroup, via hugetlb_cgroup_init,
hugetlb_cgroup_have_usage,
Normally the pointer to the cgroup to uncharge hangs off the struct
page, and gets queried when it's time to free the page. With
hugetlb_cgroup reservations, this is not possible. Because it's possible
for a page to be reserved by one task and actually faulted in by another
task.
The best place
in
the resv_map. See patch for details.
Signed-off-by: Mina Almasry
[1]: https://www.kernel.org/doc/html/latest/vm/hugetlbfs_reserv.html
Changes in v3:
- Addressed comments of Hillf Danton:
- Added docs.
- cgroup_files now uses enum.
- Various readability improvements.
- Addressed comments of Mike
These counters will track hugetlb reservations rather than hugetlb
memory faulted in. This patch only adds the counter, following patches
add the charging and uncharging of the counter.
---
include/linux/hugetlb.h | 16 +-
mm/hugetlb_cgroup.c | 111
On Fri, Aug 16, 2019 at 9:29 AM Mike Kravetz wrote:
>
> On 8/15/19 4:04 PM, Mina Almasry wrote:
> > On Wed, Aug 14, 2019 at 9:46 AM Mike Kravetz
> > wrote:
> >>
> >> On 8/13/19 4:54 PM, Mike Kravetz wrote:
> >>> On 8/8/19 4:13 PM, Mina Almasr
On Wed, Aug 14, 2019 at 8:54 PM Hillf Danton wrote:
>
>
> On Thu, 8 Aug 2019 16:13:36 -0700 Mina Almasry wrote:
> >
> > These counters will track hugetlb reservations rather than hugetlb
> > memory faulted in. This patch only adds the counter, following p
On Tue, Aug 13, 2019 at 4:54 PM Mike Kravetz wrote:
>
> On 8/8/19 4:13 PM, Mina Almasry wrote:
> > For shared mappings, the pointer to the hugetlb_cgroup to uncharge lives
> > in the resv_map entries, in file_region->reservation_counter.
> >
> > When a file_regi
On Wed, Aug 14, 2019 at 9:46 AM Mike Kravetz wrote:
>
> On 8/13/19 4:54 PM, Mike Kravetz wrote:
> > On 8/8/19 4:13 PM, Mina Almasry wrote:
> >> For shared mappings, the pointer to the hugetlb_cgroup to uncharge lives
> >> in the resv_map entries, in fi
On Sat, Aug 10, 2019 at 11:58 AM Mike Kravetz wrote:
>
> On 8/9/19 12:42 PM, Mina Almasry wrote:
> > On Fri, Aug 9, 2019 at 10:54 AM Mike Kravetz
> > wrote:
> >> On 8/8/19 4:13 PM, Mina Almasry wrote:
> >>> Problem:
> >>> Currently ta
On Fri, Aug 9, 2019 at 1:39 PM Mike Kravetz wrote:
>
> On 8/9/19 11:05 AM, Mina Almasry wrote:
> > On Fri, Aug 9, 2019 at 4:27 AM Michal Koutný wrote:
> >>> Alternatives considered:
> >>> [...]
> >> (I did not try that but) have you conside
On Fri, Aug 9, 2019 at 10:54 AM Mike Kravetz wrote:
>
> (+CC Michal Koutný, cgro...@vger.kernel.org, Aneesh Kumar)
>
> On 8/8/19 4:13 PM, Mina Almasry wrote:
> > Problem:
> > Currently tasks attempting to allocate more hugetlb memory than is
> > available get
>
On Fri, Aug 9, 2019 at 4:27 AM Michal Koutný wrote:
>
> (+CC cgro...@vger.kernel.org)
>
> On Thu, Aug 08, 2019 at 12:40:02PM -0700, Mina Almasry
> wrote:
> > We have developers interested in using hugetlb_cgroups, and they have
> > expressed
> > dissatisfac
Normally the pointer to the cgroup to uncharge hangs off the struct
page, and gets queried when it's time to free the page. With
hugetlb_cgroup reservations, this is not possible. Because it's possible
for a page to be reserved by one task and actually faulted in by another
task.
The best place
For shared mappings, the pointer to the hugetlb_cgroup to uncharge lives
in the resv_map entries, in file_region->reservation_counter.
When a file_region entry is added to the resv_map via region_add, we
also charge the appropriate hugetlb_cgroup and put the pointer to that
in
The tests use both shared and private mapped hugetlb memory, and
monitors the hugetlb usage counter as well as the hugetlb reservation
counter. They test different configurations such as hugetlb memory usage
via hugetlbfs, or MAP_HUGETLB, or shmget/shmat, and with and without
MAP_POPULATE.
---
These counters will track hugetlb reservations rather than hugetlb
memory faulted in. This patch only adds the counter, following patches
add the charging and uncharging of the counter.
---
include/linux/hugetlb.h | 2 +-
mm/hugetlb_cgroup.c | 86 +
2
in
the resv_map. See patch for details.
Signed-off-by: Mina Almasry
[1]: https://www.kernel.org/doc/html/latest/vm/hugetlbfs_reserv.html
Changes in v2:
- Split the patch into a 5 patch series.
- Fixed patch subject.
Mina Almasry (5):
hugetlb_cgroup: Add hugetlb_cgroup reservation counter
Augments hugetlb_cgroup_charge_cgroup to be able to charge hugetlb
usage or hugetlb reservation counter.
Adds a new interface to uncharge a hugetlb_cgroup counter via
hugetlb_cgroup_uncharge_counter.
Integrates the counter with hugetlb_cgroup, via hugetlb_cgroup_init,
hugetlb_cgroup_have_usage,
On Thu, Aug 8, 2019 at 1:23 PM shuah wrote:
>
> On 8/8/19 1:40 PM, Mina Almasry wrote:
> > Problem:
> > Currently tasks attempting to allocate more hugetlb memory than is
> > available get
> > a failure at mmap/shmget time. This is thanks to Hugetlbfs Reservatio
in
the resv_map. See patch for details.
[1]: https://www.kernel.org/doc/html/latest/vm/hugetlbfs_reserv.html
Signed-off-by: Mina Almasry
---
include/linux/hugetlb.h | 10 +-
include/linux/hugetlb_cgroup.h| 19 +-
mm/hugetlb.c | 256
From: Mina Almasry
Date: Tue, Apr 23, 2019 at 2:32 PM
To: Mina Almasry, Greg Thelen, Shakeel B, overlayfs
Cc: Alexander Viro, open list:FILESYSTEMS (VFS and infrastructure), open list
> On Fri, Apr 12, 2019 at 4:11 PM Mina Almasry wrote:
> >
> > These 3 locks are acquired
On Fri, Apr 12, 2019 at 4:11 PM Mina Almasry wrote:
>
> These 3 locks are acquired simultaneously in different order causing
> deadlock:
>
> https://syzkaller.appspot.com/bug?id=00f119b8bb35a3acbcfafb9d36a2752b364e8d66
>
> =
On Tue, Apr 23, 2019 at 7:28 AM Miklos Szeredi wrote:
>
> Cc: linux-unionfs
>
> On Thu, Apr 11, 2019 at 6:48 PM Mina Almasry wrote:
> >
> > These 3 locks are acquired simultaneously in different order causing
> > deadlock:
> >
>
y[depth]);
*** DEADLOCK ***
Solution: I establish this locking order for these locks:
1. ovl_i_mutex_dir_key
2. p->lock
3. sig->cred_guard_mutex
In this change i fix the locking order of exec.c, which is the only
instance that voilates this order.
Signed-off-by: Mina Almasry
---
fs/exe
88 matches
Mail list logo
