Re: OMAPFB: CMA allocation failures

[Minchan Kim]

Hello,

On Tue, Oct 15, 2013 at 09:49:51AM +0300, ÐÐÐÐÐÐ ÐÐÐÐÑÑÐÐ wrote:
>  Hi
> 
>  >-------- ÐÑÐÐÐÐÐÐÐÐ ÐÐÑÐÐ --------
>  >ÐÑ:  Tomi Valkeinen 
>  >ÐÑÐÐÑÐÐ: Re: OMAPFB: CMA allocation failures
>  >ÐÐ: ÐÐÐÐÐÐ ÐÐÐÐÑÑÐÐ
> 	
>  >ÐÐÐÑÐÑÐÐÐ ÐÐ: ÐÐÐÐÐÐÐÐÐÐ, 2013, ÐÐÑÐÐÐÑÐ 14 09:04:35 EEST
>  >
>  >
>  >Hi,
>  >
>  >On 12/10/13 17:43, ÐÐÐÐÐÐ ÐÐÐÐÑÑÐÐ 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 framebuffer
>  >> 
>  >> errors 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.
>  >> 
>  >> 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?
> 
>  >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.
> 
>  >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.

-- 
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/