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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
