Hello,
I've run into a CMA-related issue while testing a DMA engine driver with
dmatest on a Renesas R-Car ARM platform.
When allocating contiguous memory through CMA the kernel prints the following
messages to the kernel log.
[ 99.770000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed
[ 124.220000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed
[ 127.550000] alloc_contig_range test_pages_isolated(6b845, 6b846) failed
[ 132.850000] alloc_contig_range test_pages_isolated(6b845, 6b846) failed
[ 151.390000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed
[ 166.490000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed
[ 181.450000] alloc_contig_range test_pages_isolated(6b845, 6b846) failed
I've stripped the dmatest module down as much as possible to remove any
hardware dependencies and came up with the following implementation.
-----------------------------------------------------------------------------
/*
* CMA test module
*
* Copyright (C) 2014 Laurent Pinchart
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
#include <linux/delay.h>
#include <linux/dma-mapping.h>
#include <linux/freezer.h>
#include <linux/kthread.h>
#include <linux/module.h>
#include <linux/moduleparam.h>
#include <linux/slab.h>
#include <linux/wait.h>
static unsigned int num_threads = 4;
module_param(num_threads, uint, S_IRUGO | S_IWUSR);
static unsigned int iterations = 100000;
module_param(iterations, uint, S_IRUGO | S_IWUSR);
struct cma_test_thread {
struct list_head node;
struct task_struct *task;
bool done;
};
static DECLARE_WAIT_QUEUE_HEAD(thread_wait);
static LIST_HEAD(threads);
static int cma_test_thread(void *data)
{
struct cma_test_thread *thread = data;
unsigned int i = 0;
set_freezable();
while (!kthread_should_stop() && i < iterations) {
dma_addr_t dma;
void *mem;
mem = dma_alloc_coherent(NULL, 32, &dma, GFP_KERNEL);
usleep_range(1000, 2000);
if (mem)
dma_free_coherent(NULL, 32, mem, dma);
else
printk(KERN_INFO "allocation error @%u\n", i);
++i;
}
thread->done = true;
wake_up(&thread_wait);
return 0;
}
static bool cma_test_threads_done(void)
{
struct cma_test_thread *thread;
list_for_each_entry(thread, &threads, node) {
if (!thread->done)
return false;
}
return true;
}
static int cma_test_init(void)
{
struct cma_test_thread *thread, *_thread;
unsigned int i;
for (i = 0; i < num_threads; ++i) {
thread = kzalloc(sizeof(*thread), GFP_KERNEL);
if (!thread) {
pr_warn("No memory for thread %u\n", i);
break;
}
thread->task = kthread_create(cma_test_thread, thread,
"cmatest-%u", i);
if (IS_ERR(thread->task)) {
pr_warn("Failed to create thread %u\n", i);
kfree(thread);
break;
}
get_task_struct(thread->task);
list_add_tail(&thread->node, &threads);
wake_up_process(thread->task);
}
wait_event(thread_wait, cma_test_threads_done());
list_for_each_entry_safe(thread, _thread, &threads, node) {
kthread_stop(thread->task);
put_task_struct(thread->task);
list_del(&thread->node);
kfree(thread);
}
return 0;
}
module_init(cma_test_init);
static void cma_test_exit(void)
{
}
module_exit(cma_test_exit);
MODULE_AUTHOR("Laurent Pinchart");
MODULE_LICENSE("GPL v2");
-----------------------------------------------------------------------------
Loading the module will start 4 threads that will allocate and free DMA
coherent memory in a tight loop and eventually produce the error. It seems
like the probability of occurrence grows with the number of threads, which
could indicate a race condition.
The tests have been run on 3.18-rc1, but previous tests on 3.16 did exhibit
the same behaviour.
I'm not that familiar with the CMA internals, help would be appreciated to
debug the problem.
--
Regards,
Laurent Pinchart
On 10/26/2014 2:09 PM, Laurent Pinchart wrote:
> Hello,
>
> I've run into a CMA-related issue while testing a DMA engine driver with
> dmatest on a Renesas R-Car ARM platform.
>
> When allocating contiguous memory through CMA the kernel prints the following
> messages to the kernel log.
>
> [ 99.770000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed
> [ 124.220000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed
> [ 127.550000] alloc_contig_range test_pages_isolated(6b845, 6b846) failed
> [ 132.850000] alloc_contig_range test_pages_isolated(6b845, 6b846) failed
> [ 151.390000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed
> [ 166.490000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed
> [ 181.450000] alloc_contig_range test_pages_isolated(6b845, 6b846) failed
>
> I've stripped the dmatest module down as much as possible to remove any
> hardware dependencies and came up with the following implementation.
>
...
>
> Loading the module will start 4 threads that will allocate and free DMA
> coherent memory in a tight loop and eventually produce the error. It seems
> like the probability of occurrence grows with the number of threads, which
> could indicate a race condition.
>
> The tests have been run on 3.18-rc1, but previous tests on 3.16 did exhibit
> the same behaviour.
>
> I'm not that familiar with the CMA internals, help would be appreciated to
> debug the problem.
>
Are you actually seeing allocation failures or is it just the messages?
The messages themselves may be harmless if the allocation is succeeding.
It's an indication that the particular range could not be isolated and
therefore another range should be used for the CMA allocation. Joonsoo
Kim had a patch series[1] that was designed to correct some problems with
isolation and from my testing it helps fix some CMA related errors. You
might try picking that up to see if it helps.
Thanks,
Laura
[1] https://lkml.org/lkml/2014/10/23/90
--
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
On Sun, Oct 26 2014, Laurent Pinchart <[email protected]> wrote:
> Hello,
>
> I've run into a CMA-related issue while testing a DMA engine driver with
> dmatest on a Renesas R-Car ARM platform.
>
> When allocating contiguous memory through CMA the kernel prints the following
> messages to the kernel log.
>
> [ 99.770000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed
> [ 124.220000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed
> [ 127.550000] alloc_contig_range test_pages_isolated(6b845, 6b846) failed
> [ 132.850000] alloc_contig_range test_pages_isolated(6b845, 6b846) failed
> [ 151.390000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed
> [ 166.490000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed
> [ 181.450000] alloc_contig_range test_pages_isolated(6b845, 6b846) failed
>
> I've stripped the dmatest module down as much as possible to remove any
> hardware dependencies and came up with the following implementation.
Like Laura wrote, the message is not (should not be) a problem in
itself:
mm/page_alloc.c:
int alloc_contig_range(unsigned long start, unsigned long end,
unsigned migratetype)
{
[…]
/* Make sure the range is really isolated. */
if (test_pages_isolated(outer_start, end, false)) {
pr_warn("alloc_contig_range test_pages_isolated(%lx, %lx) failed\n",
outer_start, end);
ret = -EBUSY;
goto done;
}
[…]
done:
undo_isolate_page_range(pfn_max_align_down(start),
pfn_max_align_up(end), migratetype);
return ret;
}
mm/cma.c:
struct page *cma_alloc(struct cma *cma, int count, unsigned int align)
{
[…]
for (;;) {
bitmap_no = bitmap_find_next_zero_area(cma->bitmap,
bitmap_maxno, start, bitmap_count, mask);
if (bitmap_no >= bitmap_maxno)
break;
bitmap_set(cma->bitmap, bitmap_no, bitmap_count);
pfn = cma->base_pfn + (bitmap_no << cma->order_per_bit);
ret = alloc_contig_range(pfn, pfn + count, MIGRATE_CMA);
if (ret == 0) {
page = pfn_to_page(pfn);
break;
}
cma_clear_bitmap(cma, pfn, count);
if (ret != -EBUSY)
break;
pr_debug("%s(): memory range at %p is busy, retrying\n",
__func__, pfn_to_page(pfn));
/* try again with a bit different memory target */
start = bitmap_no + mask + 1;
}
[…]
}
So as you can see cma_alloc will try another part of the cma region if
test_pages_isolated fails.
Obviously, if CMA region is fragmented or there's enough space for only
one allocation of required size isolation failures will cause allocation
failures, so it's best to avoid them, but they are not always avoidable.
To debug you would probably want to add more debug information about the
page (i.e. data from struct page) that failed isolation after the
pr_warn in alloc_contig_range.
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz (o o)
ooo +--<[email protected]>--<xmpp:[email protected]>--ooO--(_)--Ooo--
[ +cc Andrew Morton ]
On 10/28/2014 08:38 AM, Michal Nazarewicz wrote:
> On Sun, Oct 26 2014, Laurent Pinchart <[email protected]> wrote:
>> Hello,
>>
>> I've run into a CMA-related issue while testing a DMA engine driver with
>> dmatest on a Renesas R-Car ARM platform.
>>
>> When allocating contiguous memory through CMA the kernel prints the following
>> messages to the kernel log.
>>
>> [ 99.770000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed
>> [ 124.220000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed
>> [ 127.550000] alloc_contig_range test_pages_isolated(6b845, 6b846) failed
>> [ 132.850000] alloc_contig_range test_pages_isolated(6b845, 6b846) failed
>> [ 151.390000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed
>> [ 166.490000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed
>> [ 181.450000] alloc_contig_range test_pages_isolated(6b845, 6b846) failed
>>
>> I've stripped the dmatest module down as much as possible to remove any
>> hardware dependencies and came up with the following implementation.
>
> Like Laura wrote, the message is not (should not be) a problem in
> itself:
[...]
> So as you can see cma_alloc will try another part of the cma region if
> test_pages_isolated fails.
>
> Obviously, if CMA region is fragmented or there's enough space for only
> one allocation of required size isolation failures will cause allocation
> failures, so it's best to avoid them, but they are not always avoidable.
>
> To debug you would probably want to add more debug information about the
> page (i.e. data from struct page) that failed isolation after the
> pr_warn in alloc_contig_range.
If the message does not indicate an actual problem, then its printk level is
too high. These messages have been reported when using 3.16+ distro kernels.
Regards,
Peter Hurley
Hi Laura,
On Monday 27 October 2014 13:38:19 Laura Abbott wrote:
> On 10/26/2014 2:09 PM, Laurent Pinchart wrote:
> > Hello,
> >
> > I've run into a CMA-related issue while testing a DMA engine driver with
> > dmatest on a Renesas R-Car ARM platform.
> >
> > When allocating contiguous memory through CMA the kernel prints the
> > following messages to the kernel log.
> >
> > [ 99.770000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed
> > [ 124.220000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed
> > [ 127.550000] alloc_contig_range test_pages_isolated(6b845, 6b846) failed
> > [ 132.850000] alloc_contig_range test_pages_isolated(6b845, 6b846) failed
> > [ 151.390000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed
> > [ 166.490000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed
> > [ 181.450000] alloc_contig_range test_pages_isolated(6b845, 6b846) failed
> >
> > I've stripped the dmatest module down as much as possible to remove any
> > hardware dependencies and came up with the following implementation.
>
> ...
>
> > Loading the module will start 4 threads that will allocate and free DMA
> > coherent memory in a tight loop and eventually produce the error. It seems
> > like the probability of occurrence grows with the number of threads, which
> > could indicate a race condition.
> >
> > The tests have been run on 3.18-rc1, but previous tests on 3.16 did
> > exhibit the same behaviour.
> >
> > I'm not that familiar with the CMA internals, help would be appreciated to
> > debug the problem.
>
> Are you actually seeing allocation failures or is it just the messages?
It's just the messages, I haven't noticed allocation failures.
> The messages themselves may be harmless if the allocation is succeeding.
> It's an indication that the particular range could not be isolated and
> therefore another range should be used for the CMA allocation. Joonsoo
> Kim had a patch series[1] that was designed to correct some problems with
> isolation and from my testing it helps fix some CMA related errors. You
> might try picking that up to see if it helps.
>
> Thanks,
> Laura
>
> [1] https://lkml.org/lkml/2014/10/23/90
I've tested the patches but they don't seem to have any influence on the
isolation test failures.
--
Regards,
Laurent Pinchart
> On 10/28/2014 08:38 AM, Michal Nazarewicz wrote:
>> Like Laura wrote, the message is not (should not be) a problem in
>> itself:
>
> [...]
>
>> So as you can see cma_alloc will try another part of the cma region if
>> test_pages_isolated fails.
>>
>> Obviously, if CMA region is fragmented or there's enough space for only
>> one allocation of required size isolation failures will cause allocation
>> failures, so it's best to avoid them, but they are not always avoidable.
>>
>> To debug you would probably want to add more debug information about the
>> page (i.e. data from struct page) that failed isolation after the
>> pr_warn in alloc_contig_range.
On Tue, Oct 28 2014, Peter Hurley <[email protected]> wrote:
> If the message does not indicate an actual problem, then its printk level is
> too high. These messages have been reported when using 3.16+ distro kernels.
I think it could be argued both ways. The condition is not an error,
since in many cases cma_alloc will be able to continue, but it *is* an
undesired state. As such it's not an error but feels to me a bit more
then just information, hence a warning. I don't care either way, though.
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz (o o)
ooo +--<[email protected]>--<xmpp:[email protected]>--ooO--(_)--Ooo--
Hello,
On Tuesday 28 October 2014 09:48:26 Peter Hurley wrote:
> [ +cc Andrew Morton ]
>
> On 10/28/2014 08:38 AM, Michal Nazarewicz wrote:
> > On Sun, Oct 26 2014, Laurent Pinchart wrote:
> >> Hello,
> >>
> >> I've run into a CMA-related issue while testing a DMA engine driver with
> >> dmatest on a Renesas R-Car ARM platform.
> >>
> >> When allocating contiguous memory through CMA the kernel prints the
> >> following messages to the kernel log.
> >>
> >> [ 99.770000] alloc_contig_range test_pages_isolated(6b843, 6b844)
> >> failed
> >> [ 124.220000] alloc_contig_range test_pages_isolated(6b843, 6b844)
> >> failed
> >> [ 127.550000] alloc_contig_range test_pages_isolated(6b845, 6b846)
> >> failed
> >> [ 132.850000] alloc_contig_range test_pages_isolated(6b845, 6b846)
> >> failed
> >> [ 151.390000] alloc_contig_range test_pages_isolated(6b843, 6b844)
> >> failed
> >> [ 166.490000] alloc_contig_range test_pages_isolated(6b843, 6b844)
> >> failed
> >> [ 181.450000] alloc_contig_range test_pages_isolated(6b845, 6b846)
> >> failed
> >>
> >> I've stripped the dmatest module down as much as possible to remove any
> >> hardware dependencies and came up with the following implementation.
> >
> > Like Laura wrote, the message is not (should not be) a problem in
> > itself:
>
> [...]
>
> > So as you can see cma_alloc will try another part of the cma region if
> > test_pages_isolated fails.
> >
> > Obviously, if CMA region is fragmented or there's enough space for only
> > one allocation of required size isolation failures will cause allocation
> > failures, so it's best to avoid them, but they are not always avoidable.
> >
> > To debug you would probably want to add more debug information about the
> > page (i.e. data from struct page) that failed isolation after the
> > pr_warn in alloc_contig_range.
[ 94.730000] __test_page_isolated_in_pageblock: failed at pfn 6b845: buddy 0
count 0 migratetype 4 poison 0
[ 94.740000] alloc_contig_range test_pages_isolated(6b845, 6b846) failed
(-16)
[ 202.140000] __test_page_isolated_in_pageblock: failed at pfn 6b843: buddy 0
count 0 migratetype 4 poison 0
[ 202.150000] alloc_contig_range test_pages_isolated(6b843, 6b844) failed
(-16)
(4 is MIGRATE_CMA)
> If the message does not indicate an actual problem, then its printk level is
> too high. These messages have been reported when using 3.16+ distro kernels.
The messages got me worried, and if there's nothing to worry about, that's bad
:-)
--
Regards,
Laurent Pinchart
Having test_pages_isolated failure message as a warning confuses
users into thinking that it is more serious than it really is. In
reality, if called via CMA, allocation will be retried so a single
test_pages_isolated failure does not prevent allocation from
succeeding.
Demote the warning message to an info message and reformat it such
that the text “failed” does not appear and instead a less worrying
“PFNS busy” is used.
Signed-off-by: Michal Nazarewicz <[email protected]>
---
mm/page_alloc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 372e3f3..e2731eb 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6431,13 +6431,12 @@ int alloc_contig_range(unsigned long start, unsigned long end,
/* Make sure the range is really isolated. */
if (test_pages_isolated(outer_start, end, false)) {
- pr_warn("alloc_contig_range test_pages_isolated(%lx, %lx) failed\n",
- outer_start, end);
+ pr_info("%s: [%lx, %lx) PFNs busy\n",
+ __func__, outer_start, end);
ret = -EBUSY;
goto done;
}
-
/* Grab isolated pages from freelists. */
outer_end = isolate_freepages_range(&cc, outer_start, end);
if (!outer_end) {
--
2.1.0.rc2.206.gedb03e5
On 10/28/2014 12:57 PM, Michal Nazarewicz wrote:
>> On 10/28/2014 08:38 AM, Michal Nazarewicz wrote:
>>> Like Laura wrote, the message is not (should not be) a problem in
>>> itself:
>>
>> [...]
>>
>>> So as you can see cma_alloc will try another part of the cma region if
>>> test_pages_isolated fails.
>>>
>>> Obviously, if CMA region is fragmented or there's enough space for only
>>> one allocation of required size isolation failures will cause allocation
>>> failures, so it's best to avoid them, but they are not always avoidable.
>>>
>>> To debug you would probably want to add more debug information about the
>>> page (i.e. data from struct page) that failed isolation after the
>>> pr_warn in alloc_contig_range.
>
> On Tue, Oct 28 2014, Peter Hurley <[email protected]> wrote:
>> If the message does not indicate an actual problem, then its printk level is
>> too high. These messages have been reported when using 3.16+ distro kernels.
>
> I think it could be argued both ways. The condition is not an error,
> since in many cases cma_alloc will be able to continue, but it *is* an
> undesired state. As such it's not an error but feels to me a bit more
> then just information, hence a warning. I don't care either way, though.
This "undesired state" is trivially reproducible on 3.16.y on the x86 arch;
a smattering of these will show up just building a distro kernel.
Hello,
On Mon, Nov 03, 2014 at 05:57:53PM +0100, Michal Nazarewicz wrote:
> Having test_pages_isolated failure message as a warning confuses
> users into thinking that it is more serious than it really is. In
> reality, if called via CMA, allocation will be retried so a single
> test_pages_isolated failure does not prevent allocation from
> succeeding.
>
> Demote the warning message to an info message and reformat it such
> that the text “failed” does not appear and instead a less worrying
> “PFNS busy” is used.
What do you expect from this message? Please describe it so that we can
review below message helps your goal.
>
> Signed-off-by: Michal Nazarewicz <[email protected]>
> ---
> mm/page_alloc.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 372e3f3..e2731eb 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -6431,13 +6431,12 @@ int alloc_contig_range(unsigned long start, unsigned long end,
>
> /* Make sure the range is really isolated. */
> if (test_pages_isolated(outer_start, end, false)) {
> - pr_warn("alloc_contig_range test_pages_isolated(%lx, %lx) failed\n",
> - outer_start, end);
> + pr_info("%s: [%lx, %lx) PFNs busy\n",
> + __func__, outer_start, end);
> ret = -EBUSY;
> goto done;
> }
>
> -
> /* Grab isolated pages from freelists. */
> outer_end = isolate_freepages_range(&cc, outer_start, end);
> if (!outer_end) {
> --
> 2.1.0.rc2.206.gedb03e5
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to [email protected]. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
--
Kind regards,
Minchan Kim
On 11/04/2014 12:43 AM, Minchan Kim wrote:
> Hello,
>
> On Mon, Nov 03, 2014 at 05:57:53PM +0100, Michal Nazarewicz wrote:
>> Having test_pages_isolated failure message as a warning confuses
>> users into thinking that it is more serious than it really is. In
>> reality, if called via CMA, allocation will be retried so a single
>> test_pages_isolated failure does not prevent allocation from
>> succeeding.
>>
>> Demote the warning message to an info message and reformat it such
>> that the text “failed” does not appear and instead a less worrying
>> “PFNS busy” is used.
>
> What do you expect from this message? Please describe it so that we can
> review below message helps your goal.
I expect this message to not show up in logs unless there is a real problem.
This message is trivially reproducible on a 10GB x86 machine on 3.16.y
kernels configured with CONFIG_DMA_CMA.
On Tue, Nov 04 2014, Peter Hurley <[email protected]> wrote:
> On 11/04/2014 12:43 AM, Minchan Kim wrote:
>> Hello,
>>
>> On Mon, Nov 03, 2014 at 05:57:53PM +0100, Michal Nazarewicz wrote:
>>> Having test_pages_isolated failure message as a warning confuses
>>> users into thinking that it is more serious than it really is. In
>>> reality, if called via CMA, allocation will be retried so a single
>>> test_pages_isolated failure does not prevent allocation from
>>> succeeding.
>>>
>>> Demote the warning message to an info message and reformat it such
>>> that the text “failed” does not appear and instead a less worrying
>>> “PFNS busy” is used.
>>
>> What do you expect from this message? Please describe it so that we can
>> review below message helps your goal.
>
> I expect this message to not show up in logs unless there is a real problem.
So frankly I don't care. Feel free to send a patch removing the message
all together. I'll be happy to ack it.
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz (o o)
ooo +--<[email protected]>--<xmpp:[email protected]>--ooO--(_)--Ooo--
On 11/04/2014 08:35 AM, Michal Nazarewicz wrote:
> On Tue, Nov 04 2014, Peter Hurley <[email protected]> wrote:
>> On 11/04/2014 12:43 AM, Minchan Kim wrote:
>>> Hello,
>>>
>>> On Mon, Nov 03, 2014 at 05:57:53PM +0100, Michal Nazarewicz wrote:
>>>> Having test_pages_isolated failure message as a warning confuses
>>>> users into thinking that it is more serious than it really is. In
>>>> reality, if called via CMA, allocation will be retried so a single
>>>> test_pages_isolated failure does not prevent allocation from
>>>> succeeding.
>>>>
>>>> Demote the warning message to an info message and reformat it such
>>>> that the text “failed” does not appear and instead a less worrying
>>>> “PFNS busy” is used.
>>>
>>> What do you expect from this message? Please describe it so that we can
>>> review below message helps your goal.
>>
>> I expect this message to not show up in logs unless there is a real problem.
>
> So frankly I don't care. Feel free to send a patch removing the message
> all together. I'll be happy to ack it.
I'd rather just remove CMA allocation from the iommu providers on x86.