OMAPFB: CMA allocation failures

-------- D?N?D,D3D,D 1/2 D?D>>D 1/2 D 3/4 D?D,N?D 1/4 D 3/4 --------
D?N?: D?D2D?D1D>>D 3/4 D?D,D 1/4 D,N?N?D 3/4 D2
D?N?D 1/2 D 3/4 N?D 1/2 D 3/4 : Re: OMAPFB: CMA allocation failures
D?D 3/4 : Tomi Valkeinen
D?D.D?N?D?N?DuD 1/2 D 3/4 D 1/2 D?: D!N?N?D'D?, 2013, D?DoN?D 3/4 D 1/4 D2N?D, 16 09:33:51 EEST

Hi Tomi,

Quoted 6 lines

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.

Quoted 4 lines

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.

Quoted 5 lines

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.

Quoted 1 line

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

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

Quoted 54 lines

-------- Оригинално писмо --------
От: Ивайло Димитров
Относно: Re: OMAPFB: CMA allocation failures До: Tomi Valkeinen
Изпратено на: Сряда, 2013, Октомври 16 09:33:51 EEST

Hi Tomi,

Quoted 6 lines

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.

Quoted 4 lines

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.

Quoted 5 lines

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.

Quoted 1 line

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