OMAPFB: CMA allocation failures
Hi
Quoted 38 lines
-------- D?N?D,D3D,D 1/2 D?D>>D 1/2 D 3/4 D?D,N?D 1/4 D 3/4 -------- D?N?: Tomi Valkeinen
D?N?D 1/2 D 3/4 N?D 1/2 D 3/4 : Re: OMAPFB: CMA allocation failures D?D 3/4 : D?D2D?D1D>>D 3/4 D?D,D 1/4 D,N?N?D 3/4 D2D?D.D?N?D?N?DuD 1/2 D 3/4 D 1/2 D?: D?D 3/4 D 1/2 DuD'DuD>>D 1/2 D,Do, 2013, D?DoN?D 3/4 D 1/4 D2N?D, 14 09:04:35 EEST
Hi,
Quoted 27 lines · On 12/10/13 17:43, D?D2D?D1D>>D 3/4 D?D,D 1/4 D,N?N?D 3/4 D2 wrote:
Hi Tomi,
patch http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/131269.html modifies omapfb driver to use DMA API to allocate framebuffer memory instead of preallocating VRAM.
With this patch I see a lot of:
Jan 1 06:33:27 Nokia-N900 kernel: [ 2054.879577] cma: dma_alloc_from_contiguous(cma c05f5844, count 192, align 8) Jan 1 06:33:27 Nokia-N900 kernel: [ 2054.914215] cma: dma_alloc_from_contiguous(): memory range at c07df000 is busy, retrying Jan 1 06:33:27 Nokia-N900 kernel: [ 2054.933502] cma: dma_alloc_from_contiguous(): memory range at c07e1000 is busy, retrying Jan 1 06:33:27 Nokia-N900 kernel: [ 2054.940032] cma: dma_alloc_from_contiguous(): memory range at c07e3000 is busy, retrying Jan 1 06:33:27 Nokia-N900 kernel: [ 2054.966644] cma: dma_alloc_from_contiguous(): memory range at c07e5000 is busy, retrying Jan 1 06:33:27 Nokia-N900 kernel: [ 2054.976867] cma: dma_alloc_from_contiguous(): memory range at c07e7000 is busy, retrying Jan 1 06:33:27 Nokia-N900 kernel: [ 2055.038055] cma: dma_alloc_from_contiguous(): memory range at c07e9000 is busy, retrying Jan 1 06:33:27 Nokia-N900 kernel: [ 2055.038116] cma: dma_alloc_from_contiguous(): returned (null) Jan 1 06:33:27 Nokia-N900 kernel: [ 2055.038146] omapfb omapfb: failed to allocate framebuffererrors while trying to play a video on N900 with Maemo 5 (Fremantle) on top of linux-3.12rc1. It is deffinitely the CMA that fails to allocate the memory most of the times, but I wonder how reliable CMA is to be used in omapfb. I even reserved 64MB for CMA, but that made no difference. If CMA is disabled, the memory allocation still fails as obviously it is highly unlikely there will be such a big chunk of continuous free memory on RAM limited device like N900.
One obvious solution is to just revert the removal of VRAM memory allocator, but that would mean I'll have to maintain a separate tree with all the implications that brings.
Quoted 6 lines
Quoted 1 line
What would you advise on how to deal with the issue?
I've not seen such errors, and I'm no expert on CMA. But I guess the contiguous memory area can get fragmented enough no matter how hard one tries to avoid it. The old VRAM system had the same issue, although it was quite difficult to hit it.
I am using my n900 as a daily/only device since the beginning of 2010, never seen such an issue with video playback. And as a maintainer of one of the community supported kernels for n900 (kernel-power) I've never had such an issue reported. On stock kernel and derivatives of course. It seems VRAM allocator is virtually impossible to fail, while with CMA OMAPFB fails on the first video after boot-up.
When saying you've not seen such an issue - did you actually test video playback, on what device and using which distro? Did you use DSP accelerated decoding?
Quoted 4 lines
64MB does sound quite a lot, though. I wonder what other drivers are using CMA, and how do they manage to allocate so much memory and fragment it so badly... With double buffering, N900 should only need something like 3MB for the frame buffer.
Sure, 64 MB is a lot, but I just wanted to see if that would make any difference. And for 720p 3MB is not enough, something like 8MB is needed.
Quoted 4 lines
With a quick glance I didn't find any debugfs or such files to show information about the CMA area. It'd be helpful to find out what's going on there. Or maybe normal allocations are fragmenting the CMA area, but for some reason they cannot be moved? Just guessing.
I was able to track down the failures to:
http://lxr.free-electrons.com/source/mm/migrate.c#L320
So it seems the problem is not that CMA gets fragmented, rather some pages cannot be migrated. Unfortunately, my knowledge stops here. Someone from the mm guys should be involved in the issue as well? I am starting to think there is some serious issue with CMA and/or mm I am hitting on n900. As it is not the lack of free RAM that is the problem -
"echo 3>/proc/sys/vm/drop_caches" results in more that 45MB of free RAM according to free.
Quoted 3 lines
There's also
dma_declare_contiguous()that could be used to reserve memory for omapfb. I have not used it, and I have no idea if it would help here. But it's something you could try.
dma_declare_contiguous() won't help IMO, it just reserves CMA area that is private to the driver, so it is used instead of the global CMA area, but I don't see how that would help in my case.
Anyway, what about reverting VRAM allocator removal and migrating it to DMA API, the same way DMA coherent pool is allocated and managed? Or simply revering VRAM allocator removal :) ?
Regards,
Ivo
--
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>
Quoted 5 lines · Ивайло Димитров
I am using my n900 as a daily/only device since the beginning of 2010, never seen such an issue with video playback. And as a maintainer of one of the community supported kernels for n900 (kernel-power) I've never had such an issue reported. On stock kernel and derivatives of course. It seems VRAM allocator is virtually impossible to fail, while with CMA OMAPFB fails on the first video after boot-up.
Yes, I think with normal fb use it's quite difficult to fragment VRAM allocator too much.
Quoted 2 lines
When saying you've not seen such an issue - did you actually test video playback, on what device and using which distro? Did you use DSP accelerated decoding?
No, I don't have a rootfs with DSP, and quite rarely test video playback. But the VRAM allocator was removed a year ago, and this is the first time I've seen anyone have issues with the CMA.
Quoted 8 lines
I was able to track down the failures to:
http://lxr.free-electrons.com/source/mm/migrate.c#L320So it seems the problem is not that CMA gets fragmented, rather some pages cannot be migrated. Unfortunately, my knowledge stops here. Someone from the mm guys should be involved in the issue as well? I am starting to think there is some serious issue with CMA and/or mm I am hitting on n900. As it is not the lack of free RAM that is the problem -
"echo 3>/proc/sys/vm/drop_caches" results in more that 45MB of free RAM according to free.
I think we should somehow find out what the pages are that cannot be migrated, and where they come from.
So there are "anonymous pages without mapping" with page_count(page) !=
1. I have to say I don't know what that means =). I need to find some time to study the mm.
Quoted 3 lines
dma_declare_contiguous()won't help IMO, it just reserves CMA area that is private to the driver, so it is used instead of the global CMA area, but I don't see how that would help in my case.
If the issue is not about fragmentation, then I think you're right, dma_declare_contiguous won't help.
Quoted 2 lines
Anyway, what about reverting VRAM allocator removal and migrating it to DMA API, the same way DMA coherent pool is allocated and managed? Or simply revering VRAM allocator removal :) ?
Well, as I said, you're the first one to report any errors, after the change being in use for a year. Maybe people just haven't used recent enough kernels, and the issue is only now starting to emerge, but I wouldn't draw any conclusions yet.
If the CMA would have big generic issues, I think we would've seen issues earlier. So I'm guessing it's some driver or app in your setup that's causing the issues. Maybe the driver/app is broken, or maybe that specific behavior is not handled well by CMA. In both case I think we need to identify what that driver/app is.
I wonder how I could try to reproduce this with a generic omap3 board...
Tomi
Hello,
Quoted 64 lines · Ивайло Димитров
Hi
Quoted 38 lines
-------- Оригинално писмо --------
От: Tomi Valkeinen
Относно: Re: OMAPFB: CMA allocation failures
До: Ивайло ДимитровИзпратено на: Понеделник, 2013, Октомври 14 09:04:35 EEST
Hi,
Quoted 27 lines · Ивайло Димитров
Hi Tomi,
patch http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/131269.html modifies omapfb driver to use DMA API to allocate framebuffer memory instead of preallocating VRAM.
With this patch I see a lot of:
Jan 1 06:33:27 Nokia-N900 kernel: [ 2054.879577] cma: dma_alloc_from_contiguous(cma c05f5844, count 192, align 8) Jan 1 06:33:27 Nokia-N900 kernel: [ 2054.914215] cma: dma_alloc_from_contiguous(): memory range at c07df000 is busy, retrying Jan 1 06:33:27 Nokia-N900 kernel: [ 2054.933502] cma: dma_alloc_from_contiguous(): memory range at c07e1000 is busy, retrying Jan 1 06:33:27 Nokia-N900 kernel: [ 2054.940032] cma: dma_alloc_from_contiguous(): memory range at c07e3000 is busy, retrying Jan 1 06:33:27 Nokia-N900 kernel: [ 2054.966644] cma: dma_alloc_from_contiguous(): memory range at c07e5000 is busy, retrying Jan 1 06:33:27 Nokia-N900 kernel: [ 2054.976867] cma: dma_alloc_from_contiguous(): memory range at c07e7000 is busy, retrying Jan 1 06:33:27 Nokia-N900 kernel: [ 2055.038055] cma: dma_alloc_from_contiguous(): memory range at c07e9000 is busy, retrying Jan 1 06:33:27 Nokia-N900 kernel: [ 2055.038116] cma: dma_alloc_from_contiguous(): returned (null) Jan 1 06:33:27 Nokia-N900 kernel: [ 2055.038146] omapfb omapfb: failed to allocate framebuffererrors while trying to play a video on N900 with Maemo 5 (Fremantle) on top of linux-3.12rc1. It is deffinitely the CMA that fails to allocate the memory most of the times, but I wonder how reliable CMA is to be used in omapfb. I even reserved 64MB for CMA, but that made no difference. If CMA is disabled, the memory allocation still fails as obviously it is highly unlikely there will be such a big chunk of continuous free memory on RAM limited device like N900.
One obvious solution is to just revert the removal of VRAM memory allocator, but that would mean I'll have to maintain a separate tree with all the implications that brings.
Quoted 6 lines
Quoted 1 line
What would you advise on how to deal with the issue?
I've not seen such errors, and I'm no expert on CMA. But I guess the contiguous memory area can get fragmented enough no matter how hard one tries to avoid it. The old VRAM system had the same issue, although it was quite difficult to hit it.
I am using my n900 as a daily/only device since the beginning of 2010, never seen such an issue with video playback. And as a maintainer of one of the community supported kernels for n900 (kernel-power) I've never had such an issue reported. On stock kernel and derivatives of course. It seems VRAM allocator is virtually impossible to fail, while with CMA OMAPFB fails on the first video after boot-up.
When saying you've not seen such an issue - did you actually test video playback, on what device and using which distro? Did you use DSP accelerated decoding?
Quoted 4 lines
64MB does sound quite a lot, though. I wonder what other drivers are using CMA, and how do they manage to allocate so much memory and fragment it so badly... With double buffering, N900 should only need something like 3MB for the frame buffer.
Sure, 64 MB is a lot, but I just wanted to see if that would make any difference. And for 720p 3MB is not enough, something like 8MB is needed.
Quoted 7 lines
Quoted 4 lines
With a quick glance I didn't find any debugfs or such files to show information about the CMA area. It'd be helpful to find out what's going on there. Or maybe normal allocations are fragmenting the CMA area, but for some reason they cannot be moved? Just guessing.
I was able to track down the failures to:
http://lxr.free-electrons.com/source/mm/migrate.c#L320
That path is for anonymous page migration so the culprit I can think of is that you did get_user_pages on those anonymous pages for pin them. Right?
If so, it's no surpse that fails the migration and CMA doesn't work.
Signature · 2 lines
Kind regards, Minchan Kim