Re: [maemo-developers] problem with dspmp3sink (was: problem with gstreamer and dsppcm)
On Monday 21 August 2006 18:34, Charles 'Buck' Krasic wrote: 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. Thanks for the information, this is interesting. I tried swap a long time ago on IT2005, that was done in order to make gcc work on Nokia 770 to try compiling something before I installed scratchbox :) Anyway, I did not like the stability as gcc started to fail with internal compiler errors. So I decided not to use swap as long as it is enough memory for what I need. Also there was some swap related report about the problem with mplayer: http://www.internettablettalk.com/forums/showpost.php?p=20068postcount=96 But maybe I should give swap another try on IT2006 and see if it helps to improve stability. By the way, I already asked this question in the mailing list long time ago, but are there any tools for hardware diagnostics on Nokia 770? Something like memtest86 could probably be very useful. Though availablility of hardware diagnostics tools could probably result in more devices getting returned for replacement with otherwise undetected problems and have negative impact on Nokia profit (just joking). ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] problem with dspmp3sink (was: problem with gstreamer and dsppcm)
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
Re: [maemo-developers] problem with dspmp3sink (was: problem with gstreamer and dsppcm)
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
