Originally Posted by Tigerite

Which changes were those? I think they're all present in the git repository - plus an update to BFS 404 and ck's latest patchsets (although there's one more I'll be posting today, an update to the most recent mm-lru_cache_add_lru_tail-1.patch). If by lxp's wl12xx patches you mean these ones I'm pretty sure they are there too, as of "kernel-power v47 -> kernel-bfs" (minus the meta-package patch). I need to recompile the bleeding-edge modules against the latest headers and modules, which I'll try to do at some point today as well, along with fcam-drivers.

Oh and I've had no distortion since running 404, even with the sched_reset_on_fork patch in place - this may have been because I raised CONFIG_HZ to 300 (from 100, although I'm not sure this is needed any more since 404 apparently "addresses a long-standing bug that affected all configurations, but was only demonstrable on lower Hz configurations (i.e. 100Hz) that caused fluctuating performance and latencies"), or because I'm using the pulseaudio package by Jyri Sarha (of Nokia) from here:

Code:

The old free list implementation used objects in FIFO style. This is
bad because it tries keep all the objects ever used alive and in
memory. This minimizes the changes that an allocated object is already
in cache. When there is shortage of physical memory this may also
increase change that newly allocated object is swapped out. LIFO
(e.g. stack) style free list should help these issues. Like the old
one the new implementation is also lock free. This version (v2.1) of
the patch has a potential weakness fixed. The previous version (2.0)
did segfault when popping from empty flist, this does not.

.. or because of the ck patchsets. I'm going to lower the CONFIG_HZ back to 100 today to eliminate that possibility at least.

PS I also compiled with CONFIG_WATCHDOG=n and haven't noticed any side effects from doing so.

Originally Posted by epitaph

BFS-Kernel is really good especially when you need Flash. But with the wonderpatch and cgroups tuning BFS is useless. Where can I find BFS 404?

Originally Posted by Tigerite

I couldn't have put it better myself - besides which the cgroups patch can also cause regressions, because it's heuristic. By the way I am running with swappiness 0 (!) with the -ck patches and BFS 404, which runs beautifully on my device. I might even try to put dirty_ratio to 1 (as recommended with 404 - at the moment I've got it set to 8)..

Also, I've included a 404 version of the patch mentioned here, but disabled (set to 0) both parameters by default. So, should anyone wish to have a similar effect to the "200 lines miracle patch", the following knobs are available:

Code:

Threads are kept at the same fork_depth as their parent process, and can
optionally have their CPU entitlement all managed as one process together
by enabling the group_thread_accounting feature. This feature is disabled
by default in this patch, as many desktop applications such as firefox,
amarok, etc are multithreaded. By disabling this feature and enabling the
fork_depth_penalty feature it favours CPU towards desktop
applications. This latter feature is also disabled in this patch by default.

Extensive testing is required to ensure this does not cause regressions in
common workloads.

There are two sysctls to enable/disable these features.

They are in /proc/sys/kernel/

group_thread_accounting - groups CPU accounting by threads
fork_depth_penalty - penalises according to depth of forking from init

Please take particular note of the part in bold. This patch does, in ck's own words, add a very small amount of overhead to the kernel (even when disabled) but I think it's worth it.

Originally Posted by MastaG

So he doesn't want it in mainline?
But will it be merged in the power kernel then?
Or do we have to compile it ourselfs?