maemo.org - Talk
Page 17 of 31 « First 71516 17 181927 Last »
Show 40 post(s) from this thread on one page

maemo.org - Talk (https://talk.maemo.org/index.php)
-   Maemo 5 / Fremantle (https://talk.maemo.org/forumdisplay.php?f=40)
-   -   BFS for the power kernel (https://talk.maemo.org/showthread.php?t=58780)

Tigerite 2011-05-30 07:38
Re: BFS for the power kernel
 
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.

epitaph 2011-05-30 08:11
Re: BFS for the power kernel
 
Quote:
Originally Posted by Tigerite (Post 1018360)
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.
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?

Hurrian 2011-05-30 09:15
Re: BFS for the power kernel
 
Quote:
Originally Posted by epitaph (Post 1018370)
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?
http://cache.ohinternet.com/images/d...L_WUT_PEAR.jpg
BFS is a CPU scheduler, not a "renice cgroups" patch. Con Kolivas already explained the differences. Maemo is already doing a terrible job of trying to implement it's own renice'd cgroups (see syspart). This is where BFS comes in. BFS has simple prioritization AND it helps fix the "Linux is using 100% CPU... on I/O!" thing CFS has. Which helps on a device with 256MB RAM, constantly swapping, and accessing large amounts of data from the eMMC for no reason at all.

Tigerite 2011-05-30 09:31
Re: BFS for the power kernel
 
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.

epitaph 2011-05-30 10:51
Re: BFS for the power kernel
 
Quote:
Originally Posted by Tigerite (Post 1018420)
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.
I hate to repeat myself but with cgroups enabled and some additional tuning my device is really fast. I don't want to start a fight here but where can I find 404 and Con's patch didn't make it upstream. Anyway who wants Flash?

Tigerite 2011-05-30 12:09
Re: BFS for the power kernel
 
At the moment, you have to build the kernel from the git tree for BFS 404. My device is also very smooth and fast with BFS, and there's very little swap I/O (I've yet to see more than ~70000 bytes used in /proc/swaps). None of Con's work has ever made it upstream, if you mean into the mainline kernel, there are many historical reasons for this and I would have thought we all know them by now.. moreover he doesn't want BFS in mainline.

MastaG 2011-05-30 12:17
Re: BFS for the power kernel
 
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?

MONVMENTVM 2011-05-30 12:24
Re: BFS for the power kernel
 
A power kernel with the latest BFS patch packaged in a .deb would be really great.

Hurrian 2011-05-30 12:35
Re: BFS for the power kernel
 
Quote:
Originally Posted by MastaG (Post 1018545)
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?
CK doesn't want it in mainline because the Linux devs will just **** it up. Read bfs-faq.txt, lots of rage against the kernel.org devs and you'll know why BFS was made. Probably epitaph needs to read it too.

Tigerite 2011-05-30 13:02
Re: BFS for the power kernel
 
You can't just patch kernel-power with BFS. However, you can do the reverse; the BFS kernel has already got all the power47 patches, plus the -ck patchset which I backported to 2.6.28 (to the best of my ability). Talking of which, the git tree has now been updated with the latest to correlate with 404 as closely as possible.


All times are GMT. The time now is 18:48.
Page 17 of 31 « First 71516 17 181927 Last »
Show 40 post(s) from this thread on one page

vBulletin® Version 3.8.8