Hi All,

I've tried just about every performance/battery/"smoothness" patch available over the last 12 months, including :-
- power kernel scaling (250<>805) with vdd1+2
- powervr.ini
- swappolube/IO tuning
- swap on class 10 SD
- "raid" emmc+sd swapfiles
- reduced desktops (1)
- disabled watchdogs
- simplified (i.e. no) transitions
- un-niced xorg
- disabled xorg access control

I've just installed the "cgroup" automatic process grouping patch on top of all these, and even with all the above enabled the patch makes a really noticeable difference to how rapidly the device responds to input, renders web pages, switches tasks, pretty much everything except heavy IO.

To take this patch forward, I think this change belongs in the kernel, rather than a bunch of shell scripts in userland.

It's been implemented in the mainline linux kernels since 2.6.38 (march 2011) see http://kernelnewbies.org/Linux_2_6_38.

Ideally we'd need a diff against 2.6.28 that incorporates the automatic process grouping changes from 2.6.38 and submit it to pali for consideration in kernel-power48.

Over to, er someone, to create the diff. I'll have a go at it myself, but you might be waiting a long time, so I hope someone beats me to it.

Mmmmhm, I see it's tweakable to a fair degree, but the main result automatic process grouping brings is the grouping itself which works well with the kernel's CFS scheduler. Tweaking resource allocation per group will doubtless be worth doing though.

One thing - the rt.period/runtime and memory limit settings do take effect, but these lines :-
echo "512" > /dev/cgroup/cpu/cpu.shares
echo "512" > /dev/cgroup/cpu/desktop/cpu.shares
echo "512" > /dev/cgroup/cpu/applications/cpu.shares
If you cat those settings after modifying them, they've reverted to their old values (1024, 6144, 2048 respectively).

As for notify on release, those are supposed to clean up old cgroups when the last process in the group dies - probably not that necessary on the n900 as we generally don't have users logging in/out that often.

From what I can figure out, the secret sauce is that instead of CFS enumerating 150-200 processes to decide who gets resources, it instead enumerates just 3-4 cgroups, reducing the scheduling load by a factor of 50.

Un-nice - remove the "-n -8" from dsmetool when xorg runs. It doesn't really have any performance benefit, but by putting xorg back in the mix with all other tasks, it does at least cause the CPU scaling to drop to minimum more often, so it saves some power.

Looks like i missed a lot of posts here

ok
1-) FOR the values provided by epitaph

i think just like thingonaspring those values are the most teweakable

echo "555555" > /dev/cgroup/cpu/cpu.rt_runtime_us
echo "600000" > /dev/cgroup/cpu/cpu.rt_period_us
echo "95M" > /dev/cgroup/cpu/user/memory.limit_in_bytes
echo "555555" > /dev/cgroup/cpu/user/cpu.rt_runtime_us
echo "600000" > /dev/cgroup/cpu/user/cpu.rt_period_us
echo "25M" > /dev/cgroup/cpu/desktop/memory.limit_in_bytes

although haven't tested them (and will not be able to until next year)

2-) for the deb
Mmm i think it will take a long time to get done (im extreamly busy these days) and i also asked for misiak to make it (with a gui for me) but he is lost these days (never goes online) idk why

Hi Karam and others. I installed this patch twice now (first removed old installation and then tested without the patch and then reinstalled the patch). I did not see any noticable difference. It is quite confusing as some report a huge difference. Just wanted to share this.

it makes a big difference when stressing the CPU of the device

I understand this and when I test this. I do not see any difference.

isnt just CSSU maemo15 is enough for a speedy-est N900 ?i wish if there was a patch for battery life enhancement or less cpu usage.in both cases power consumption would be less and N900 will be JF-17.

Youre not stressing it enough.


Enabling SMart Reflex is by far the best way to increase battery life