I'm seeing this consistently between my N900 and 2 others. Device is snappy for the first day of use, then the swap usage gradually increases and the device really starts to slow down over the course of a few days as the swap usage gets higher and higher.

I found it quite amazing that the device is already 50MB into swap when initially powered up. Having owned an N800 and N810 (which had 128MB real memory, and were able to run swapless) I found this very surprising. I wonder what has blown the memory usage out so far for it to need swap with absolutely no apps running.

I wonder if there are some features and daemons we could safely disable to reduce the memory usage and turn the swapfile off? This would permanently fix the "device runs sluggish" problem. If any process has a memory leak, it will get OOMed (killed by the kernel for using too much memory) and we'll be able to identify it a lot easier.

Thoughts, anyone?

Swap used after powering up is caching. Linux swap doesn't work like Windows swap which is only used when memory gets full. Using swap for cache can help increase responsiveness. The sluggishness begins when some memory pages of active applications get swapped out. But when this happens you know that you wouldn't have got that far without swap space.

The device is very unresponsive during flash disk IO. I think this is the real problem with swap here. Doesn't the controller use DMA?

I generally give it a reboot every few days anyway, keeps it fresh and also means saves my desktop widget positions.

Sometimes it slows down but I think thats because its doing checking the repos for updates or doing something in the background I don't know about.

pycage I think you're wrong here. Swap on Linux purely swaps out the least-often-accessed pages of memory in preference for file cache according to the settings in /proc/sys/vm (especially the setting "swappiness" - incidentally, why oh why oh why is this set at "100" by default ? Nobody knowledgeable so far afaik has been able to give any plausible explanation for this.. ).

In any case: supposing you're correct and its "for caching" as you say. Is it therefore caching from fast flash (256MB NAND root filesystem) to slow flash (mmcblk0p3) ???! This defeats the purpose of a cache (ie the purpose of speeding up access to a slow medium) - it would be better no not cache to the slower medium at all.

Indeed no - its not swapping for caching; it seems to be swapping out of necessity. The processes are malloc'ing more memory than the device physically has. Have a look at the output of "ps aux" and add up the VSZ column. Have a look at the output of "free". If it's swapping for caching purposes then try this: disable swap and see if your phone doesn't crash hard: "sudo swapoff /dev/mmcblk0p3"

Am I wrong?

so, can we disable compositing? Can we disable virtual desktops? Can we disable the media indexer. Would any of this help to reduce the amount of memory consumed by standard processes in maemo 5? If anyone has any hints or tricks they've found, feel free to share them here!

Edit: pycage - did you mean "process data in memory can be swapped out so that the then free RAM (ultra fast) can be used for file cache" ? Upon second reading it occurred to me that this is what you may have meant by "swap is used for cache" (which is technically incorrect)

Normally I try to reboot daily but now this thing has been running couple of days.

So I rebooted just and this device is just totally different again. Programs open fast, webpages load faster and when I tap close button it closes application immediately . I´m starting to doubt that it really chokes itself with app.manager. I run it couple of times daily.

I'm going to give swappiness = 0 a serious run for a while to attempt to determine which processes' memory allocations are growing (and getting swapped out). I'll try to remember to report back here with any findings.

I realise this will probably make the device run slower as there'll be less disk cache in RAM, but its a diagnostic measure.

It's not the lack of dma that makes it unresponsive. If data that isn't in ram is needed for an app, then for that app to continue to run, that data must be fetched. The app continues running when the data has arrived. Other apps can continue to run.

If it was not using DMA, then everything would halt.

Of course, if the task switcher or X is one of the apps waiting for data to arrive it looks like everything stopped..

Hello,

I also noticed this problem, and am determined to find the real solution.

I've had my n900 running for more than 5 days now, and the slowdown started, as expected. Looking at top revealed nothing, no apparent excess memory usage, or cpu load.

My first suspect was the browser daemon, so I restarted it with the following command:

/etc/init.d/tablet-browser-daemon.init restart

Of course this needs root.

After a little while this seems to have helped, the interface seems to be usable again, switching windows is snappy, and a lot less GUI lag than before the command. I'm posting this from the device.

I'm not saying this is the solution, but it might help others. I'll try to keep my device running for as long as possible, and will try to diagnose this if it slows down again. I'm far from an expert, but I know my way around Linux a bit to try this I think.

Anyway I'll post again if I find something new. I hope that this is solvable with enoguh effort, I'd like my phone to have as good uptime as my servers without problems.

Tamas

I have to add. That in my previous post I suspected my intensive app manager usage, but actually it might be surprise surprise some widget. Removed almost all. Left only conversations and calendar and suddenly everything felt little snappier.