On 15/10/13 09:49, Ивайло Димитров wrote: > 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. > 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. > 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. 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. > 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. > 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
Attachment:
signature.asc
Description: OpenPGP digital signature