I think these guys get their fix from restarting hildon-desktop rather than flushing memory structures. Notice how the original lemming typed all the lines in succession (including killing the desktop at the end) and claimed performance gain.

Anyway, I have been running iostat for the last 8 days. A bit more time, and we may know more about the problem.

i think killing the hildon-desktop is all u need for now so u dont have to restart the phone. Until the bugs are solved, i guess this will do for now..

And if I were to put my finger on it, it has to be the SGX. Doesn't dmesg say something about "pvr: recovering a gazillion unfreed resources" when you kill hildon-desktop after a long session?

Dunno, personally, I subscribe to ShadowJK's theory of swap partition acting slow once it rolls over after a few days. This, and the swappiness=100 killing all the heavy apps like Fennec (once I set it to 30, Fennec, Video Player, and other sluggish apps become perfectly usable).

PS: Looked at the iostat results. Nothing special there, except maybe for swap writes grossly exceeding swap reads.

did you try swapoff -> swapon then? Though I would doubt the issue were on some core kernel component.

I have not, but ShadowJK claims that swapoff->swapon fixes the problem. Well, for another few days, anyway.

A side effect of doing swapoff-swapon with no alternate swap location is that a lot of daemons shut down, and then come back once swap is reactivated. Phone runs pretty sluggish for a few minutes as these daemons come back to life, but seems pretty nice afterwards.

Anyone wanna write a small script that looks periodically at /proc/diskstats to detect rollover, waits until night and device idle and device on carger, creates temporary swap on $HOME, turns off and on mmcblk0p3, deactivates and deletes temporary swap?

Interesting stuff...

Possibly preloaded applications -- iirc desktop will preload some programs like Clock when free memory is higher than a threshold defined in .desktop file . How is it calculated I don't remember but seems that just adding a new, empty swap area causes it to increase.

Note that phone will appear faster after swapoff/on cycle even without any swap backend related slowness present, since quite an "acceptable" number of open applications fit in RAM, specially after desktop unloads all the preloaded ones.
Of course if this issue is noticeable it should quickly manifest when trying to start extra ones.

I hope I get to test that next time I try to do an idle battery life test.

Btw, if writes are slowed down, wouldn't a heavy swapiness actually help -- as it would nice to keep as much free RAM as possible to minimize the amount of frames to page out when you're interacting with the device?

if it's any help, hildon-desktop misbehaves when you constantly go into the application list and back out again. do it just a few times (maybe 3-4 times). if you have catorise installed, try it by popping in and out of a few categories.

so what i do now is i put all my frequently used applications as shortcuts on my desktop.

Check this thread I made:
http://talk.maemo.org/showthread.php?t=58935