WTF? I am acting against you ?!? Boy, I don't know you and I don't have nothing in personal against you. period.

On the other hand lets have a look at your so called patches:

speedpatch - I've asked you several times on your dedicated thread for an explanation what exactly it does. Your answer was either none or a hyperlinks to sites with explanation what cgroups do and how moving a terminal launched applications into a cgroup will give them more CPU shares (the famous 200 lines patch). Which means nothing in the context of n900 and the fact that cgroups are already mounted(by Nokia) under /syspart. And there is system daemon written by Nokia which uses settings in /usr/share/policy/current/syspart.conf for process distribution among /syspart subdirectories. While it is not impossible an individual to gain better results in cgroups process distribution than the whole Nokia Maemo team (which have had experience from 4 or so Maemo iterations) I highly doubt that is the case.

The other problem with your speedpatch is the fact that it makes priority management incompatible with vanilla, i.e. if tomorrow CSSU team makes a decision to move camera-ui into a higher-priority cgroup while a video is recorded, all users who have CSSU and your patch will have broken systems and will complain "booo, my video stutters, you stupid CSSU developers".

And while I understand and agree that things like responsiveness are hard to measure, why it is so hard to put an explanation in you "magic patch" thread OP how is your process distribution done? No, the kernel does not automatically distribute newly created processes under different cgroup (as it is written in speedpatch description). The truth is that newly created processes are put in the "root" cgroup directory (even if not visible there) and someone has to move the process into a different cgroup so restrictions (as CPU shares and memory limit) to apply. I still fail to find who and how moves processes between cgroups. And there is not a word in your explanations about that. At least there was no by the time I stopped to follow your "miracle patch" thread.

What could be the reason for placebo effect (i.e. speedup of the system reported by some users) is that speedpatch (along with batterypatch) has a new version almost every day and as it requires a reboot, here it is, speedpatch/batterypatch users have uptime no more than 48 hours, so effects like swap fragmentation does not appear.

batterypatch - AIUI those scripts play with two things based on whether device is locked or not:

1. vfs_cache_pressure
2. CPU clocks

vfs_cache_pressure - what is the rationale behind that? I think it was Estel the last one to explain why it has nothing to do with battery life at all. And I don't see your explanation why messing up with file cache will decrease battery consumption. Care to explain?

cpu clocks - well, I don't think it is userland job to mess with CPU frequencies, but could be wrong. Anyway, AFAIK your entire work on batterypatch is based on trial/error way. Which would not be a problem, if you were playing with your device only, but you are playing with the devices of all users who had this installed from extras-devel. Every single day (or so) there is a new version, with slightly changed parameters on a WFM basis.

And I fail to see any measurement proving that batterypatch actually reduces idle current or current under load. Your latest batterypatch requires KP49, ain't? And enables SmartReflex? Well, it is SmartReflex that increases battery life, not your trickery with CPU frequencies and dbus-monitoring whether device is locked or not. Prove me wrong, please, make some measurement,i.e.

in offline mode,device with KP49, dsp profile 125-805 has standby current of:

xx mA without batterypatch
xx mA with batterypatch

the same device running abc background task has current of:

xx mA without batterypatch
xx mA with batterypatch

and finishes the job for:

xx s without batterypatch
xx s with batterypatch

etc.

Only by making such measurements you can prove batterypatch does anything but problems.