Re: OMAPFB: CMA allocation failures
From: ÐÐÐÐÐÐ ÐÐÐÐÑÑÐÐ
Date: Wed Oct 23 2013 - 17:59:49 EST
Hi,
I wonder if there is any progress on the issue? Do you need me to send more data? Or
should I raise the issue with the CMA maintainer?
Regards,
Ivo
>-------- ÐÑÐÐÐÐÐÐÐÐ ÐÐÑÐÐ --------
>ÐÑ: ÐÐÐÐÐÐ ÐÐÐÐÑÑÐÐ
>ÐÑÐÐÑÐÐ: Re: OMAPFB: CMA allocation failures
>ÐÐ: Tomi Valkeinen
>ÐÐÐÑÐÑÐÐÐ ÐÐ: ÐÑÑÐÐ, 2013, ÐÐÑÐÐÐÑÐ 16 09:33:51 EEST
>
>
> Hi Tomi,
>
>>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.
>
>I put some more traces in the point of failure, the result:
>page_count(page) == 2, page->flags == 0x0008025D, which is:
>PG_locked, PG_referenced, PG_uptodate, PG_dirty, PG_active, PG_arch_1, PG_unevictable
>Whatever those mean :). I have no idea how to identify where those pages come from.
>
>>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.
>
>I am (almost) sure I am the first one to test video playback on OMAP3 with DSP video
>acceleration, using recent kernel and Maemo5 on n900 :). So there is high probability the
>issue was not reported earlier because noone have tested it thoroughly after the change.
>
>>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.
>
>What I know is going on, is that there is heavy fs I/O at the same time - there is
>a thumbnailer process running in background which tries to extract thumbnails of all video
>files in the system. Also, there are other processes doing various jobs (e-mail fetching, IM
>accounts login, whatnot). And in addition Xorg mlocks parts of its address space. Of course
>all this happens with lots of memory being swapped in and out. I guess all this is related.
>
>However, even after the system has settled, the CMA failures continue to happen. It looks like
>some pages are allocated from CMA which should not be.
>
>>I wonder how I could try to reproduce this with a generic omap3 board...
>
>I can always reproduce it here (well, not on generic board, but I guess it is even better to
>test in real-life conditions), so if you need some specific tests or traces or whatever, I
>can do them for you.
>
>Regards,
>Ivo
>
--
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/