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: