* Re: [Bug 201085] New: Kernel allows mlock() on pages in CMA without migrating pages out of CMA first
[not found] <bug-201085-27@https.bugzilla.kernel.org/>
@ 2018-09-12 19:47 ` Andrew Morton
2018-09-12 22:19 ` Mike Kravetz
0 siblings, 1 reply; 4+ messages in thread
From: Andrew Morton @ 2018-09-12 19:47 UTC (permalink / raw)
To: linux-mm, Joonsoo Kim, Laura Abbott; +Cc: bugzilla-daemon, tpearson
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Tue, 11 Sep 2018 03:59:11 +0000 bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=201085
>
> Bug ID: 201085
> Summary: Kernel allows mlock() 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: akpm@linux-foundation.org
> Reporter: tpearson@raptorengineering.com
> Regression: No
>
> Pages 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.
>
> --
> You are receiving this mail because:
> You are the assignee for the bug.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Bug 201085] New: Kernel allows mlock() on pages in CMA without migrating pages out of CMA first
2018-09-12 19:47 ` [Bug 201085] New: Kernel allows mlock() on pages in CMA without migrating pages out of CMA first Andrew Morton
@ 2018-09-12 22:19 ` Mike Kravetz
2018-09-14 3:09 ` Aneesh Kumar K.V
0 siblings, 1 reply; 4+ messages in thread
From: Mike Kravetz @ 2018-09-12 22:19 UTC (permalink / raw)
To: Andrew Morton, linux-mm, Joonsoo Kim, Laura Abbott
Cc: bugzilla-daemon, tpearson, Aneesh Kumar K . V
On 09/12/2018 12:47 PM, Andrew Morton wrote:
>
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Tue, 11 Sep 2018 03:59:11 +0000 bugzilla-daemon@bugzilla.kernel.org wrote:
>
>> https://bugzilla.kernel.org/show_bug.cgi?id=201085
>>
>> Bug ID: 201085
>> Summary: Kernel allows mlock() 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: akpm@linux-foundation.org
>> Reporter: tpearson@raptorengineering.com
>> Regression: No
>>
>> Pages 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.
>>
>> --
>> 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/20180906054342.25094-2-aneesh.kumar@linux.ibm.com
This report seems to be suggesting a more general solution/change. Wondering
if there is any overlap with this and Aneesh's work.
--
Mike Kravetz
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Bug 201085] New: Kernel allows mlock() on pages in CMA without migrating pages out of CMA first
2018-09-12 22:19 ` Mike Kravetz
@ 2018-09-14 3:09 ` Aneesh Kumar K.V
2018-09-14 3:12 ` Aneesh Kumar K.V
0 siblings, 1 reply; 4+ messages in thread
From: Aneesh Kumar K.V @ 2018-09-14 3:09 UTC (permalink / raw)
To: Mike Kravetz, Andrew Morton, linux-mm, Joonsoo Kim, Laura Abbott
Cc: bugzilla-daemon, tpearson
On 9/13/18 3:49 AM, Mike Kravetz wrote:
> On 09/12/2018 12:47 PM, Andrew Morton wrote:
>>
>> (switched to email. Please respond via emailed reply-to-all, not via the
>> bugzilla web interface).
>>
>> On Tue, 11 Sep 2018 03:59:11 +0000 bugzilla-daemon@bugzilla.kernel.org wrote:
>>
>>> https://bugzilla.kernel.org/show_bug.cgi?id=201085
>>>
>>> Bug ID: 201085
>>> Summary: Kernel allows mlock() 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: akpm@linux-foundation.org
>>> Reporter: tpearson@raptorengineering.com
>>> Regression: No
>>>
>>> Pages 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.
>>>
>>> --
>>> 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/20180906054342.25094-2-aneesh.kumar@linux.ibm.com
>
> 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Bug 201085] New: Kernel allows mlock() on pages in CMA without migrating pages out of CMA first
2018-09-14 3:09 ` Aneesh Kumar K.V
@ 2018-09-14 3:12 ` Aneesh Kumar K.V
0 siblings, 0 replies; 4+ messages in thread
From: Aneesh Kumar K.V @ 2018-09-14 3:12 UTC (permalink / raw)
To: Mike Kravetz, Andrew Morton, linux-mm, Joonsoo Kim, Laura Abbott
Cc: bugzilla-daemon, tpearson
On 9/14/18 8:39 AM, Aneesh Kumar K.V wrote:
> On 9/13/18 3:49 AM, Mike Kravetz wrote:
>> On 09/12/2018 12:47 PM, Andrew Morton wrote:
>>>
>>> (switched to email.A Please respond via emailed reply-to-all, not via
>>> the
>>> bugzilla web interface).
>>>
>>> On Tue, 11 Sep 2018 03:59:11 +0000
>>> bugzilla-daemon@bugzilla.kernel.org 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 allows mlock() 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: akpm@linux-foundation.org
>>>> A A A A A A A A A A Reporter: tpearson@raptorengineering.com
>>>> A A A A A A A A Regression: No
>>>>
>>>> Pages 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.
>>>>
>>>> --
>>>> 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).A Added him on Cc:
>> https://lkml.kernel.org/r/20180906054342.25094-2-aneesh.kumar@linux.ibm.com
>>
>>
>> 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.
>
Another option is to look at the possibility of having something similar
to prctl that will avoid allocation from CMA region?
-aneesh
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2018-09-14 3:12 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-201085-27@https.bugzilla.kernel.org/>
2018-09-12 19:47 ` [Bug 201085] New: Kernel allows mlock() on pages in CMA without migrating pages out of CMA first Andrew Morton
2018-09-12 22:19 ` Mike Kravetz
2018-09-14 3:09 ` Aneesh Kumar K.V
2018-09-14 3:12 ` Aneesh Kumar K.V
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.