maemo.org - Talk - Improving responsiveness under high memory load

maemo.org - Talk (https://talk.maemo.org/index.php)

- Nokia N900 (https://talk.maemo.org/forumdisplay.php?f=44)

- - Improving responsiveness under high memory load (https://talk.maemo.org/showthread.php?t=68125)

Re: Improving responsiveness under high memory load

haha I was joking about the ram! i'm sure its susceptible to the same silicon degredation over a few years though?

Smartreflex is disabled by default, sure, i'm just saying people messing with the overclocking stuff are likely to enable it. And they will get longer cpu life.

Re: Improving responsiveness under high memory load

No I mean even enabling VDD it still has no effect as it's hardcodedly disabled by nokia after PR1.0?

Re: Improving responsiveness under high memory load

its hard to verify it does anything but on my n900 it freezes when i enable smartreflex at clocks > 805mhz. otherwise i can get it to 950. so it must be lowering the voltage too much. nokia never said anything about disabling it completely, just by default it would remain disabled.
nokia might have broken it in their stock kernel, but its able to turn on still with titan's

Re: Improving responsiveness under high memory load

Quote:

overclocking will damage your system.

Most of the time, this isn't true. The Cortex A8 was made to run at 600Mhz to greater than 1Ghz, and that's quoting ARM's website. So, if you keep it at or under 1Ghz, you're not gonna hurt the phone since it was made to run at that speed anyway.

Re: Improving responsiveness under high memory load

Quote:

Originally Posted by mattbutsko (Post 923498)

Depends on the specific batch of Cortex A8 chips. I think there's more than one Cortex A8. With the chips being rated (or certified I guess) to run at certain speeds without much harm. Which is probably why some N900 are more unstable when overclocked with the same voltage settings than other N900s.

Re: Improving responsiveness under high memory load

I wonder what happens when I make my device entirely and fully swapless? Looking at Conky there is always about 25% free memory left! Isn't Linux supposed to eat all free memory for diskcache and so on? Isn't it the same idea? Btw I removed python from being swapped too and my device seems to be very responsive now!

#!/bin/sh
LD_PRELOAD=/usr/lib/mlocker.so
exec python2.5 "$@"

Re: Improving responsiveness under high memory load

Quote:

Originally Posted by epitaph (Post 923511)

I'm fairly certain that Conky only displays memory allocated to processes for the "memory used" graph. The rest of the memory you can assume has been (or will soon be) used by the kernel for disk cache/buffers.

Quote:

Originally Posted by epitaph (Post 923511)

Btw I removed python from being swapped too and my device seems to be very responsive now!

I think that's probably placebo-- most if not all python processes are running as user, not root, and mlocker.so will only work if the process is running with root privileges. If you really want to see how your device runs without swap, then type the following at the console:

Code:

sudo gainroot

swapoff -a

My guess is, if that even succeeds (it didn't on my N900, there just wasn't enough RAM), it might briefly run nice and fast if you don't have any applications open and you don't have any widgets on your home screen, but once you open something (anything, really) it will quickly slow down and then things will start crashing. Maemo 5 really does not want to run with only 256 MB of memory, and trying to squish it in there means that there won't be room for any sort of disk caching. Even desktop Linux machines with 8 GB of RAM will benefit from having swap enabled, just because there is memory that really isn't accessed very often and if it isn't resident in RAM then that space can be used for more caches.

The question of which apps to lock into memory is tricky, because the more RAM you lock up, the less responsive anything else in the system will be. I decided the X server was important enough to lock just because any application that displays anything on the screen, which is most of them, will have to talk to the X server, so it's a common bottleneck. I'm not nearly as sure about the rest, though.

I'm actually considering writing a kernel patch to fine-tune the swapping behavior for different processes; it might be more effective (and efficient) than continuing with the LD_PRELOAD tricks I've been using.

Re: Improving responsiveness under high memory load

Quote:

Originally Posted by Cirne (Post 916529)

[SIZE="5"]

I've always been a little disappointed in how the N900 handles when all its RAM is used up and it starts going to swap. It doesn't happen that often, but sometimes I have four or five browser windows open plus the email client and maybe an xterm... Typically the device pretty much stops responding, and even pressing control-backspace, the power button, or even the lock slider takes ages to work. And if I get a phone call? Sometimes I don't even get the phone window to show up before the phone stops ringing.

Taking a look using htop, it seems like the browser process and X itself are fighting over RAM-- the browser is using what appears to be around 500 or so megs of memory (most of it swapped out, obviously) and both it and X are in disk-wait as both of them page fault to work together on handling the same request. So, I've altered my N900 to make the Xorg process lock all its memory into RAM. Which means that RAM space can't ever be used by other processes, but in my experience, X swapping out is never a good thing on a workstation, and that's probably triply true on a handheld device.

Note that the other problem here is bad behaviour in the kernel when under memory pressure while doing IO to a device that has slow IO. On desktop linux, this is very apparent when you do any disk IO to (say) a slow USB flash disk, on kernels (AFAIUR) 2.6.27 through 2.6.33.

There have been a number of fixes addressing this bug, starting around 2.6.34.

On desktop linux distros, just one of these fixes on top of 2.6.33 makes a *huge* difference.

It might be worthwhile looking at getting these patches into the kernel (since almost all the IO is to slow block devices).

Re: Improving responsiveness under high memory load

Yep, http://www.phoronix.com/scan.php?pag...item&px=OTAyNw
2.6.38 will feature all responsiveness patches.

Re: Improving responsiveness under high memory load

Quote:

Originally Posted by Cirne (Post 923356)

So I had to try and fix things in the rootfs filesystem using the meego rescue initrd, which was complicated because I didn't understand ubifs at all.

For anyone else that falls into that trap (assuming you're using the meego rescue initrd, or any other initrd that gives you a standard shell):

1. Append ubi.mtd=rootfs to the kernel command line.
2. Type at the shell prompt: mount -t ubifs ubi0:rootfs /mnt

Apologies for hijacking the thread.
How did you type the dash, 0, and slash? When I boot into the Meego rescue initrd, the Fn key doesn't do anything.