Siarhei, Just in case you have not done it already, enabling swap in your device can help a lot to prevent out-of-memory errors. Maybe this will help with mplayer/gstreamer stability.
I personally suspect a design flaw in the current Linux VM subsystem. I've observed that if an application allocates memory rapidly, the kernel may fail to reclaim pages quickly enough from the page and buffer caches (they are only caches after all), so it actually denies the allocation request. For example, with zero swap, on a machine with 1G of ram, and >500M of it pseudo-free (used by caches), I've seen moderate allocations fail--like when starting an application like firefox. Enabling even a small amount of swap seems to dramatically change this behaviour. -- Buck Eero Tamminen wrote: >Hi, > > > >>Also I noticed that gstreamer is not very reliable, at least when using >>it from mplayer. It can freeze or reboot the device sometimes. That's not >>something that should be expected from high level API. If I detect some >>reliable pattern in reproducing these bugs, I'll report it to bugzilla >>for sure. But right now just using mplayer and lots of seeking in video >>can cause these bugs reasonably fast. >> >> > >First I would recommend using just "top" to see whether mplayer >is either: >- Leaking memory >- Otherwise using too much memory >Either by itself or forcing gstreamer to do that. > >If that is the case, the bug is in the mplayer (or gstreamer (plugin)) >and it needs to be fixed. For debugging the leaks, I would recommend >using Valgrind on x86. > > > - Eero > >PS. The applications in the device have been done so that they integrate >into the the device memory management framework; if they have dynamic >or large memory usage, before doing large allocs, they check whether >system has enough memory for those, they react to system low memory >notifications etc. > >If an application forces the kernel to the OOM (out of memory) >situation, it will by default kill the application requesting >memory. However, if mplayer is run as root, its killing is >avoided (note most of the framework processes are run as normal >user). Also, if you're using Desktop while mplayer triggers >device OOM, it's Desktop using memory and kernel might kill it >(which reboots the device). > >FYI: Only way to handle OOM correctly is to avoid triggering it, >trying something "fancy" (in kernel) in that situation is AFAIK >wraught with deadlocks. > >_______________________________________________ >maemo-developers mailing list >maemo-developers@maemo.org >https://maemo.org/mailman/listinfo/maemo-developers > >
begin:vcard fn:Charles 'Buck' Krasic n:Krasic;Charles 'Buck' org:University of British Columbia;Department of Computer Science adr:;;201-2366 Main Mall;Vancouver;B.C.;V6T 1Z4;Canada email;internet:[EMAIL PROTECTED] title:Assistant Professor tel;work:(604) 822-5628 tel;fax:(604) 822-5485 tel;cell:(604) 313-9429 x-mozilla-html:FALSE url:http://www.cs.ubc.ca/~krasic/ version:2.1 end:vcard
_______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
