Improving responsiveness under high memory load
 

Big fat warning: if you try anything in this post, be ABSOLUTELY SURE that you can fix it if it goes wrong! You may end up needing to re-flash your N900 if you make a mistake.

I'm not sure if anyone has tried this before, but I searched and didn't find anything, so I figured I'd post it here.

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.

The above technically-heavy description is to drive away people not savvy enough to understand what's going on here, because trying what I've done can very, very easily brick your phone. If you do try this, have some sort of way to fix your phone, like the rescue ramdisk over at the Meego site. Though I suppose just reflashing would work, too, if you don't mind having to restore from a backup.

I haven't done any serious tests on this, but it SEEMS more responsive now. How much is true and how much placebo, I couldn't say.

If you want to try this, you'll need root access. Download the attached file, untar it, and move mlocker.so into /usr/lib. Edit /etc/event.d/xomap and add LD_PRELOAD=/usr/lib/mlocker.so to the beginning of the exec line, so it should look like this:

There's another copy of that file in /etc/event.replace.d/ -- I don't know why it's there, but I modified it the same way. Then reboot and pray you didn't mess anything up.

Like I said, it seems to help. It won't make your N900 any faster per se and it won't make ANY difference if you're not using up all your RAM, but if you are, things should get a little more responsive. I find that actually pressing control-backspace works better at getting me to the task switcher than half-pressing the camera button with camkeyd, but I can pretty reliably get to the switcher and close apps.

Phone app is a bit more responsive when I get a call, though not quite as much as I'd like. I'd really like to do the same thing for hildon-desktop (the window manager) and rtcom-call-ui (the phone app), and maybe systemui (the power key menu), but those are all run by maemo-launcher, so I can't do quite the same trick there. I wish there were a way to force memory page locking from outside a process in Linux, but if there is I don't know about it.

Anyway, if you've gotten this far and decide to try this, let me know if and how well it works!

Re: Improving responsiveness under high memory load
 

Overclocking makes the device pretty responsive to me....no need to fiddling w/ RAM.

Re: Improving responsiveness under high memory load
 

Sure, overclocking will help in the general case. It'll make the phone more usable under general conditions, and it will make certain operations take less time. However, overclocking won't help this performance issue at all-- it's entirely based on the speed of the flash memory, which can't be sped up by overclocking the CPU.

Give it a shot for yourself: try opening up, say, eight browser windows pointing to Facebook or some other media/content-rich website. Then try opening another application. Can you even get to the application menu? Try switching back to one of your previous browser windows. How long does it take before clicking the close button actually works?

There is another point, too-- overclocking will damage your system. It's not a matter of if, it's a matter of how much. By pushing your system's limits, you decrease the life expectancy of the hardware-- and it isn't as easy to replace a burnt-out CPU in a phone as it is in a desktop machine. What I'm talking about here, if you do it correctly, won't affect your phone's hardware at all. In a certain sense, it's like marking a program as "high-priority", only instead of affecting processor time, it affects memory usage characteristics. You aren't putting more physical load on the phone's RAM, just specifying which processes get to use it first.

Re: Improving responsiveness under high memory load
 

You could:
mv /usr/bin/rtcom-call-ui /usr/bin/rtcom-call-ui.real

cat <<EOF > /usr/bin/rtcom-call-ui
#!/bin/sh
LD_PRELOAD=/usr/lib/mlocker.so
exec \${0}.real "$@"
EOF
chmod +x /usr/bin/rtcom-call-ui
That should work... hmm might try it :)

Re: Improving responsiveness under high memory load
 

I am very much interested in tuning and making the N900 faster. Both hardware and software methods. But saying that overclocking will damage the N900 with such certainty is a bit overboard. (although, I know what you are trying to say. :p)

Yeah, my phone even at 1GHz+ is sometimes very laggy and unresponsive when even trying to pick up an incoming call. (But I have to say, my N900 is not exactly "stock")

Re: Improving responsiveness under high memory load
 

Seems to work nicely for rtcom-call-ui ; mileage may vary with others.

For example, just tried it with camera-ui and we're stuck in an endless boot cycle :)

I predict a lot a flashing. Be careful out there people ... test on your scratchbox first.

Re: Improving responsiveness under high memory load
 

Short answer: no, it won't work.

Long answer: I tried that at first (actually, a slightly more complex version of that; you can see the remnants of it in mlocker.c). The problem is that those processes aren't actually standalone binaries. The file you mention is just a symlink to maemo-invoker. maemo-invoker, in turn, talks to maemo-loader (a daemon), telling it "please run the rtcom-call-ui application". maemo-loader then opens up /usr/bin/rtcom-call-ui.launch and executes it. Only here's the rub, and why all the hassle with maemo-loader in the first place: the .launch files aren't actually executables. Oh, they're binaries, to be sure, but they're more like shared libraries with a main function. maemo-loader loads them and transfers control over to them without ever calling exec().

You can do an ls -l /proc/*/exe to see just how many processes are running with maemo-loader as their system-recognized primary executable. So, whatever hacks I'm going to do, they'll have to be more complex and target maemo-loader itself. I certainly plan to, at some point; might even throw a renice() in there too. It'd sure be keen if all the processes on the critical path didn't have to wait for page faults or processor scheduling when you get a phone call.

Re: Improving responsiveness under high memory load
 

If by "work" you mean "doesn't crash the system", then yes. If you mean "locks pages into RAM" then no. The way to see if it's working is to cat /proc/(pid)/status and see if the locked memory counter is greater than 0. There is no easy way to get this working, sadly, see my above post.

Re: Improving responsiveness under high memory load
 

I might make a package out of this if there's enough interest, probably after adding maemo-loader support and some logic to automate patching the event.d files (with a heaping load of sanity-checking for good measure). mlocker.so is the library I wrote that hacks executables into locking their own memory into RAM at startup, it (along with its source code) is in the tar.gz archive I attached to the OP.

Re: Improving responsiveness under high memory load
 

No it is completely true.
By overclocking you WILL damage the CPU faster than if you weren't overclocking in the same scenario.

No ifs, no buts.

Re: Improving responsiveness under high memory load
 

*nods*

Yep so I see. Just looking at the maemo-launcher source on gitorious now to see why camera-ui went pants on head. Would you be patching that directly? Might be worth implementing a blacklist + whitelist.

Re: Improving responsiveness under high memory load
 

So it's not a but that this will take years to happen?

Doesn't Nokia overclock the N900 at the factory before they send it to us?

Would you care to go into more depth about the damage Nokia does by overclocking?

Re: Improving responsiveness under high memory load
 

I think I'll more likely implement it as an LD_PRELOAD hack again, to minimize the impact on what is a very important system process. I'd rather not recompile it if I don't have to. And there will definitely be some sort of configurability, possibly a file in /etc listing which binaries should get the mlock treatment.

Re: Improving responsiveness under high memory load
 

The a8 comes in many clock speeds, I believe the N900 uses the one rated to 600MHz, though there are others that will officially scale to 1GHz.

We have no way of knowing how long it will take for the first a8 to pop.
It might be a case of months, years or decades, the point is we just do not know.

Re: Improving responsiveness under high memory load
 

That's right. Most likely, some other component will die way before the CPU does anyways.
I guess I've been lucky for past 11 months or so running at 1Ghz+ constant.
Ah well, I'll soon get a dual-core A9 phone or similar and overclock that. =P

Sorry for being off topic. I'll stay quiet now. :(

Re: Improving responsiveness under high memory load
 

Does mlocker.so need to be chmod'ed in anyway before one does this?

Re: Improving responsiveness under high memory load
 

It shouldn't need to be, it's in the archive with the right permissions. But, if you extract it to a VFAT partition (like in MyDocs), it might get messed up. If you want to be on the safe side, go ahead and chmod 755 the library once it's in place. It doesn't need to be SUID, though, if that's what you mean.

In other news I got started with mlock'ing those other binaries and promptly reboot-looped my N900. It took me the better part of five hours to get it running again because EARLY_SSH in kernel-power didn't work as advertised (see my post on the k-power thread for the solution). 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

Re: Improving responsiveness under high memory load
 

FYI enabling smart-reflex as part of overclocking should help with silicon degradation, it sounds like it will dynamically reduce the voltage to reduce the effects of degradation. Hopefully this counter-effects the increased temperature from overclocking :) Also the materials and process (NOT high-k and is 65nm) should provide a pretty long life compared to some CPUs. Anyways I wouldn't go so far as to say any slight overclocking will damage the cpu, but it is just wearing at an accellerated rate.

Oh yeah, thanks for the work on the scripts though, I will have to try this some time. But it might wear out my RAM! Oh I guess thats better than the flash memory...

Re: Improving responsiveness under high memory load
 

As I said: This will not increase the load on the RAM chips at all, or damage them, or make them wear out faster. RAM isn't like an LCD monitor where locking an image into place "burns it in". If the X server weren't locked into memory, then it would just be some other piece of data filling that space. There's no such thing (for all practical intents and purposes) as an "empty" memory block, you don't "turn off" memory like you do a monitor, and it doesn't harm your RAM to have part of the memory space permanently dedicated to a single process.

What it will do, however, is change the profile of the swap (i.e. flash memory) usage. The X server, which would otherwise occasionally eat up write/erase cycles by swapping out, will no longer cause any flash wear. Other processes on the system, however, will be somewhat more likely to swap out because they can't use the memory that is reserved for X, so they will cause slightly more flash wear. It's a balance, and I have no real numbers on how it might affect flash usage overall, but my intuition is that, since the X server is used so much, it would probably result in an overall decrease in flash memory usage.

Re: Improving responsiveness under high memory load
 

I thought smartreflex was disabled already? :confused:

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
 

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
 

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
 

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.

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:

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
 

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
 

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.

Re: Improving responsiveness under high memory load
 

how to untar in xterm? thx

Re: Improving responsiveness under high memory load
 

tar xvf <file> for non gzipped
tar xvzf <file> for gzipped

Re: Improving responsiveness under high memory load
 

just did this, bout to reboot.

will test tonight by downloading a big file thru transmission

thanks

Re: Improving responsiveness under high memory load
 

i thought this app would help a cpu/ram hogging app work better..

it has made no difference to transmission for me anyway.

the app is still unresponsive and locks up phone

Re: Improving responsiveness under high memory load
 

Your ignorance is showing.

Re: Improving responsiveness under high memory load
 

would it be possible to write a wrapper for the rt-comm-ui "shared library" and replace the wrapper script by a call to this wrapper instead of maemo-launcher? That would solve the shared lib issue and bring the phone app to be a "first class citizen".

Is that something doable or does maemo-launcher does extra magic that is hard to replicate?

Re: Improving responsiveness under high memory load
 

what IS your problem with me?

forgive me Im not an uber-geek like yourself, which is a good thing as I actually get laid.

Re: Improving responsiveness under high memory load
 

Hi there.

Perhaps I'm a bit late in joining in this. I was looking at using the mlock calls do similar things, and found this thread.

Any updates or new findings on the maemo-launcher business?

Basically I want to have some process not to be swapped out on the N900.

Thanks!