Originally Posted by debernardis (Post 817524)

Concerning this issue, I want to implement the small memory-freeing command that Simon describes in his blog post, saying he runs it as a cron job.

This might take some time and resources to run, since there's a sync command which writes down to the flash memory.
Given that we haven't cron by default on our devices, and I don't know how to mess with the alarmd daemon (and I'm not sure I'll ever do), I would then add an icon to run the command and free memory when the user likes to, i.e. when the device isn't going to do critical things like answering a call or shooting a video.

What do you think? Button or alarmd?

Originally Posted by P@t (Post 817878)

Adding my thanks too

But I have noticed that at least some of the parameters do not survive a reboot?! While it seems that it should.

Originally Posted by debernardis;817524
Concerning this issue, I want to implement the small memory-freeing command that Simon describes in his blog post, saying he runs it as a cron job.

[code

I run a cronjob that drops buffer cache containing pagecache, dentries and inodes, to clear out unused dirty pages (sync; echo 3 > /proc/sys/vm/drop_caches).[/code]

This might take some time and resources to run, since there's a sync command which writes down to the flash memory.
Given that we haven't cron by default on our devices, and I don't know how to mess with the alarmd daemon (and I'm not sure I'll ever do), I would then add an icon to run the command and free memory when the user likes to, i.e. when the device isn't going to do critical things like answering a call or shooting a video.

What do you think? Button or alarmd?

Originally Posted by debernardis (Post 817914)

Please control that it has installed a /etc/event.d/tuning file

Originally Posted by P@t (Post 817925)

I have the file 'tuning' and I can read the same values as in your first post.
However when I reboot, I can read for example:
40 for for the parameter dirty_ratio
while it should be 95

If I launch again the DEB, then the parameters turn to be at the correct values.

PS: some weeks ago I had modified the rcS file and did change the parameters of swappiness and page-cluster directly in the file. Could that be related? (I have serious doubt but...)

Originally Posted by debernardis (Post 817940)

@P@t: you're right. Both dirty_ratio and dirty_background_ratio don't get saved. I'm going to try to see why :)

Originally Posted by debernardis (Post 817524)

@f2thak: sorry mate. Hope you have the flasher utility at hand, or you had backupmenu to restore the pristine state. Might be that when turning it off, it hadn't written everything on flash, due to the changes in the way read and write get managed? So, maybe it's better to issue a sync before turning off?

@Frank Banul: reboot is not needed, the parameter changes are made on-the-fly during the install of the script that makes them also applied at boot time. And, they are reverted at uninstall time, when that script gets erased.

@kennibal: yes, and if you read Simon's explanation of those params, you'll find that there is one that lets silently crash the latest program you start if it elicits an out-of-memory condition, instead of getting rid of one or more background processes. It's the price to pay for the fluidity. If you try again maybe it will start correctly after a cleanup of memory.

Concerning this issue, I want to implement the small memory-freeing command that Simon describes in his blog post, saying he runs it as a cron job.

This might take some time and resources to run, since there's a sync command which writes down to the flash memory.
Given that we haven't cron by default on our devices, and I don't know how to mess with the alarmd daemon (and I'm not sure I'll ever do), I would then add an icon to run the command and free memory when the user likes to, i.e. when the device isn't going to do critical things like answering a call or shooting a video.

What do you think? Button or alarmd?

Originally Posted by debernardis (Post 816676)

Originally Posted by les_garten (Post 817975)

How often is this cron job ran? I don't know who Simon is and therefore don't know his blog. I'd like to add this to my cron jobs.

Originally Posted by shadowjk (Post 819074)

Yes, 0 makes no sense, alot of the other various stuff I've seen here and there makes no sense either, but the placebo effect seems to override new slowdowns anyway... :)

Originally Posted by debernardis (Post 819136)

So we should see which of the parameters are really useful and which ones are neutral or dangerous... By now tcp_timestamps and page-cluster are considered guilty.

Originally Posted by TiagoTiago (Post 819158)

i also wanna know the pros and cons of each change please, also, a GUI for toggling each parameter individually would be great.

Btw, why you don't put this on -devel?

Originally Posted by fms (Post 819066)

Please, correct me if I am wrong, but I doubt this one makes sense, as flash memory appears to be written in 256kB pages. So, the original number of 5 that translates into 32*4096=128kB makes more sense. You may even increase it to 6!

Originally Posted by fms (Post 819138)

I really really think someone should try and package COMPCACHE for the N900. It may make a huge difference, by providing fast intermediate swap area in RAM (where swapped out pages are stored in gzipped form).

Originally Posted by fms (Post 819139)

I know for sure that the swappiness thing helps. You can test it by running Fennec or any other memory hogging application. The kill_oob_* thing looks sane, and so does the laptop_mode (based on its description found with Google). The tcp_* stuff is petty and probably does not make any difference to the network performance (unless somebody proves otherwise). Can't say much about the rest.

Originally Posted by egoshin (Post 819175)

It would have a big impact on battery life (1) because CPU usage, and it decreases an available RAM space which is very valuable for N900 Maemo (2). So, it would decrease N900 performance.

Originally Posted by fms (Post 819196)

Not necessarily. Given how expensive MMC access operations are, gzipping most pages to, let us say, 16MB of RAM may well prove to be faster than pushing the same pages to the MMC.