Re: OMAPFB: CMA allocation failures

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 3383 bytes --]

Hi,

On 24/10/13 00:59, Ивайло Димитров wrote:
>  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?

No, I haven't had time to look at this. And frankly, I don't even have
an idea what to look for if I can't reproduce it. The issue is not about
display, but DMA allocation, of which I know very little.

So yes, I suggest you try to discuss this with CMA/DMA people.

 Tomi

> 
> 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
>  >
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]