New: Kernel allows mlock() on pages in CMA without migrating pages out of CMA first
A message that is not in the archive (sent off-list or not yet received): [email protected]/
Andrew Morton
maintainer(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).
Quoted 31 lines · On Tue, 11 Sep 2018 03:59:11 +0000 [email protected] wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=201085
Bug ID: 201085
Summary: Kernel allowsmlock()on pages in CMA without
migrating pages out of CMA first
Product: Memory Management
Version: 2.5
Kernel Version: 4.18
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Page Allocator
Assignee: [email protected]
Reporter: [email protected]
Regression: NoPages allocated in CMA are not migrated out of CMA when non-CMA memory is available and locking is attempted via
mlock(). This can result in rapid exhaustion of the CMA pool if memory locking is used by an application with large memory requirements such as QEMU.To reproduce, on a dual-CPU (NUMA) POWER9 host try to launch a VM with mlock=on and 1/2 or more of physical memory allocated to the guest. Observe full CMA pool depletion occurs despite plenty of normal free RAM available.
Signature · 2 lines
You are receiving this mail because: You are the assignee for the bug.
Quoted 37 lines · Andrew Morton
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).
Quoted 31 lines · On Tue, 11 Sep 2018 03:59:11 +0000 [email protected] wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=201085
Bug ID: 201085
Summary: Kernel allowsmlock()on pages in CMA without
migrating pages out of CMA first
Product: Memory Management
Version: 2.5
Kernel Version: 4.18
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Page Allocator
Assignee: [email protected]
Reporter: [email protected]
Regression: NoPages allocated in CMA are not migrated out of CMA when non-CMA memory is available and locking is attempted via
mlock(). This can result in rapid exhaustion of the CMA pool if memory locking is used by an application with large memory requirements such as QEMU.To reproduce, on a dual-CPU (NUMA) POWER9 host try to launch a VM with mlock=on and 1/2 or more of physical memory allocated to the guest. Observe full CMA pool depletion occurs despite plenty of normal free RAM available.
Signature · 2 lines
You are receiving this mail because: You are the assignee for the bug.
IIRC, Aneesh is working on some powerpc IOMMU patches for a similar issue (long term pinning of cma pages). Added him on Cc:
https://lkml.kernel.org/r/[email protected]
This report seems to be suggesting a more general solution/change. Wondering if there is any overlap with this and Aneesh's work.
Signature · 1 line
Mike Kravetz
Quoted 39 lines · Mike Kravetz
Quoted 37 lines · Andrew Morton
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).
Quoted 31 lines · On Tue, 11 Sep 2018 03:59:11 +0000 [email protected] wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=201085
Bug ID: 201085
Summary: Kernel allowsmlock()on pages in CMA without
migrating pages out of CMA first
Product: Memory Management
Version: 2.5
Kernel Version: 4.18
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Page Allocator
Assignee: [email protected]
Reporter: [email protected]
Regression: NoPages allocated in CMA are not migrated out of CMA when non-CMA memory is available and locking is attempted via
mlock(). This can result in rapid exhaustion of the CMA pool if memory locking is used by an application with large memory requirements such as QEMU.To reproduce, on a dual-CPU (NUMA) POWER9 host try to launch a VM with mlock=on and 1/2 or more of physical memory allocated to the guest. Observe full CMA pool depletion occurs despite plenty of normal free RAM available.
Signature · 2 lines
You are receiving this mail because: You are the assignee for the bug.
Quoted 7 lines
IIRC, Aneesh is working on some powerpc IOMMU patches for a similar issue (long term pinning of cma pages). Added him on Cc:
https://lkml.kernel.org/r/[email protected]This report seems to be suggesting a more general solution/change. Wondering if there is any overlap with this and Aneesh's work.
This is a related issue. I am looking at doing something similar to what I did with IOMMU patches. That is migrate pages out of CMA region bfore mlock.
The problem mentioned is similar to vfio. With VFIO we do pin the guest pages and that is similar with -realtime mlock=on option of Qemu.
We can endup backing guest RAM with pages from CMA area and these are different qemu options that do pin these guest pages for the lifetime of the guest.
-aneesh
Quoted 49 lines · Aneesh Kumar K.V
Quoted 39 lines · Mike Kravetz
Quoted 37 lines · Andrew Morton
(switched to email.A Please respond via emailed reply-to-all, not via the bugzilla web interface).
Quoted 31 lines · On Tue, 11 Sep 2018 03:59:11 +0000 [email protected] wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=201085
A A A A A A A A A A A A Bug ID: 201085
A A A A A A A A A A A Summary: Kernel allowsmlock()on pages in CMA without A A A A A A A A A A A A A A A A A A A A migrating pages out of CMA first A A A A A A A A A A A Product: Memory Management
A A A A A A A A A A A Version: 2.5
A A A A Kernel Version: 4.18
A A A A A A A A A A Hardware: All
A A A A A A A A A A A A A A A A OS: Linux
A A A A A A A A A A A A A A Tree: Mainline
A A A A A A A A A A A A Status: NEW
A A A A A A A A A A Severity: normal
A A A A A A A A A A Priority: P1
A A A A A A A A A Component: Page Allocator
A A A A A A A A A A Assignee: [email protected]
A A A A A A A A A A Reporter: [email protected]
A A A A A A A A Regression: NoPages allocated in CMA are not migrated out of CMA when non-CMA memory is available and locking is attempted via mlock().A This can result in rapid exhaustion of the CMA pool if memory locking is used by an application with large memory requirements such as QEMU.
To reproduce, on a dual-CPU (NUMA) POWER9 host try to launch a VM with mlock=on and 1/2 or more of physical memory allocated to the guest.A Observe full CMA pool depletion occurs despite plenty of normal free RAM available.
Signature · 2 lines
You are receiving this mail because: You are the assignee for the bug.Quoted 8 lines
IIRC, Aneesh is working on some powerpc IOMMU patches for a similar issue (long term pinning of cma pages).A Added him on Cc:
https://lkml.kernel.org/r/[email protected]This report seems to be suggesting a more general solution/change. Wondering if there is any overlap with this and Aneesh's work.
Quoted 6 lines
This is a related issue. I am looking at doing something similar to what I did with IOMMU patches. That is migrate pages out of CMA region bfore mlock.
The problem mentioned is similar to vfio. With VFIO we do pin the guest pages and that is similar with -realtime mlock=on option of Qemu.
We can endup backing guest RAM with pages from CMA area and these are different qemu options that do pin these guest pages for the lifetime of the guest.
Another option is to look at the possibility of having something similar to prctl that will avoid allocation from CMA region?
-aneesh