Reply
Thread Tools
Posts: 1,418 | Thanked: 1,541 times | Joined on Feb 2008
#31
Originally Posted by javispedro View Post
Sigh, not "RAM maximizer" programs again. The only thing this does is to temporarily increase the amount of _unused_ (aka wasted) RAM, normally used in preparation of an hibernation/s2disk.
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.
 

The Following 4 Users Say Thank You to fms For This Useful Post:
Posts: 100 | Thanked: 24 times | Joined on May 2010
#32
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..
 
javispedro's Avatar
Posts: 2,355 | Thanked: 5,249 times | Joined on Jan 2009 @ Barcelona
#33
Originally Posted by fms View Post
I think these guys get their fix from restarting hildon-desktop rather than flushing memory structures.
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?
 
Posts: 1,418 | Thanked: 1,541 times | Joined on Feb 2008
#34
Originally Posted by javispedro View Post
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.
 
javispedro's Avatar
Posts: 2,355 | Thanked: 5,249 times | Joined on Jan 2009 @ Barcelona
#35
did you try swapoff -> swapon then? Though I would doubt the issue were on some core kernel component.
 
Posts: 1,418 | Thanked: 1,541 times | Joined on Feb 2008
#36
Originally Posted by javispedro View Post
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.
 

The Following User Says Thank You to fms For This Useful Post:
Posts: 1,258 | Thanked: 672 times | Joined on Mar 2009
#37
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?
 

The Following 3 Users Say Thank You to shadowjk For This Useful Post:
javispedro's Avatar
Posts: 2,355 | Thanked: 5,249 times | Joined on Jan 2009 @ Barcelona
#38
Interesting stuff...

Originally Posted by shadowjk View Post
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.
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.

Originally Posted by shadowjk View Post
Phone runs pretty sluggish for a few minutes as these daemons come back to life, but seems pretty nice afterwards.
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?
 

The Following User Says Thank You to javispedro For This Useful Post:
Posts: 958 | Thanked: 483 times | Joined on May 2010
#39
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.
 
Posts: 214 | Thanked: 256 times | Joined on May 2010
#40
 
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 19:43.