(In reply to comment #0)
> ACTUAL OUTCOME:
> There is a delay of several seconds starting applications. The tablet becomes
> unresponsive, with CPU Load meter showing 100% but HTOP not showing any
> significant activity.

That's a very strange discrepancy, could you post the top few lines of htop
output when sorted by CPU usage ("P")?  Also, what does "free" report?

Are you by any chance using an ad-hoc WLAN connection, and if so any
similarities with bug 5712?

(In reply to comment #1)
> That's a very strange discrepancy, could you post the top few lines of htop
> output when sorted by CPU usage ("P")?  Also, what does "free" report?
I definitely will. Unfortunately, I have just rebooted the device yesterday, so
the problem has not have chance to occur yet. Waiting.

> Are you by any chance using an ad-hoc WLAN connection, and if so any
> similarities with bug 5712?
Nope. No ad-hoc WLAN connections in sight. Connected to a WiFi AP *or* eGPRS
*or* not connected at all: this does not seem to depend on the network.

This has happened for me too at least once. Because of bug #5450 I usually
reboot my device quite often, so it may be that it uptime has only once reached
7 days.

I checked free and top, but couldn't see anything specific. Next time I'll take
a closer look.

This could be related to 8723?

*** This bug has been confirmed by popular vote. ***

Comment 6 Andre Klapper 2010-08-23 17:43:38 UTC

Closing this bug report as the issue could not be reproduced. Please feel free
to reopen this report if you can provide better steps to reproduce this and if
this is still a problem in 10.2010.19-1.

Comment 7 Ryan Abel 2010-08-24 18:42:04 UTC

Using the latest update, the device becomes nearly unusable* after about 2-3
days. As far as I can tell, this is from the RAM filling up and the device
entering swap hell. I usually have XChat, FBReader, and a few SMS windows open
in the background. But the real culprits tends to be browser, Modest, and
rtcom-messaging-ui, which don't seem to decide their RAM usage based on any
open windows.

killalling all three of these processes immediately clears up the issue.


*Lag-time of about 5-7 seconds to show an SMS window, 3-5 seconds to show the
Dashboard, slow application loading, slow browser, etc. Everything you would
expect from swap hell.

(In reply to comment #7)
> But the real culprits tends to be browser, Modest, and
> rtcom-messaging-ui, which don't seem to decide their RAM usage based on any
> open windows.
Can confirm this at least for Modest. 

> *Lag-time of about 5-7 seconds to show an SMS window, 3-5 seconds to show the
> Dashboard, slow application loading, slow browser, etc. Everything you would
> expect from swap hell.
Confirming all these + the video playback starts stuttering (both video and
audio). For me, it is still at least 4-5 days before all these things start
happening.

As the problem clearly occurs in the latest firmware users have in their hands,
I am going to reopen this bug tracker. Sorry, Andre.

Comment 9 Andre Klapper 2010-08-30 18:36:29 UTC

Eero: Do you have an idea where to start tracking this down a bit?

Comment 10 Eero Tamminen 2010-08-30 19:09:56 UTC

(In reply to comment #9)
> Eero: Do you have an idea where to start tracking this down a bit?

In general this is because of:
* Memory/swap usage increase
* Processes memory getting fragmented in swap because of memory leakage
* Fragmented pieces being slower to access from swap/disk than continuous
blocks

Killing large memory users can help with this temporarily because it reduces
memory & swap usage and therefore swap fragmentation.

While w19 release had many memory leak fixes, it had also a regression in
systemui, on every screen locking it leaked a colormap which causes X server
memory to get fragmented over swap.  This and several other (smallish) memory
leaks will be fixed in next release.  So hopefully it will help for this issue
too.


(In reply to comment #7)
> But the real culprits tends to be browser, Modest, and rtcom-messaging-ui,
> which don't seem to decide their RAM usage based on any open windows.

Are they leaking memory?  You could use sp-endurance to check that.  Have some
script that saves endurance data at night and then make sure that you close all
apps/windows for the night.  To get good data, you would need to do this for
over a week without a reboot.  The postprocessing script will then show how the
whole device memory usage.

http://wiki.maemo.org/Documentation/devtools/maemo5/sp-endurance
http://wiki.maemo.org/Documentation/devtools/maemo5/sp-endurance-postproc


> killalling all three of these processes immediately clears up the issue.

Some of them implement the policy of exiting only after some time after last
window is closed.  If you don't mind slower startup times, you might even
disable pre-starting their UI processes. (for browserd engine processes this
doesn't make sense as it's startup would take too long)

Comment 11 Andre Klapper 2010-09-23 17:50:48 UTC

(In reply to comment #10)
> Are they leaking memory?  You could use sp-endurance to check that.

luarvique: Can you check?

(In reply to comment #11)
> (In reply to comment #10)
> > Are they leaking memory?  You could use sp-endurance to check that.
> luarvique: Can you check?
I may, although it requires installing a few extra packages.