3.7-ck1, BFS 426 for linux-3.7

Some degree of normality has returned to my life, so I bring to you a resync of the BFS cpu scheduler for 3.7, along with the -ck patches to date.

Apply to 3.7.x:
patch-3.7-ck1.bz2
or
patch-3.7-ck1.lrz

Broken out tarball:
3.7-ck1-broken-out.tar.bz2
or
3.7-ck1-broken-out.tar.lrz

Discrete patches:
patches

Latest BFS by itself:
3.7-sched-bfs-426.patch


People often ask me why I don't maintain a git tree of my patches or at least BFS and make it easier on myself and those who download it. As it turns out, it is actually less work only for those who download it to have a git tree and would actually be more work for me to maintain a git tree.

While I'm sure most people are shaking their head and thinking I'm just some kind of git-phobe, I'll try to explain (Note that I maintain git trees for lrzip https://github.com/ckolivas/lrzip and cgminer https://github.com/ckolivas/cgminer).

I do NOT keep track of the linux kernel patches as they come in during the development phase prior to the latest stable release. Unfortunately I simply do not have the time nor the inclination to care on that level any more about linux kernel. However I still do believe quite a lot in what BFS has to offer. If I watched each patch as it came into git, I could simply keep my fork with BFS and merge the linux kernel patches as they came in, resyncing and modifying as it went along with the changes. When new patches go into the kernel, there is a common pattern of many changes occurring shortly after they're merged, with a few fixes going in, some files being moved around a few times, and occasionally the patch backed out when it's found the patch introduces some nasty regression that proves a showstopper to it being released. Each one of these changes - fixes, moves, renames, removal, require a resync if you are maintaining a fork.

The way I've coded up the actual BFS patch itself is to be as unobtrusive as possible - it does not actually replace large chunks of code en bloc, just adding files and redirecting builds to use those new files instead of the mainline files. This is done to minimise how much effort it is to resync when new changes come. The vast majority of the time, only trivial changes need to be made for the patch to even apply. Thus applying an old patch to a new kernel just needs fixes to apply (even if it doesn't build). This is usually the first step I do in syncing BFS, and I end up with something like this after fixing the rejects:

http://ck.kolivas.org/patches/bfs/3.0/3.7/incremental/3.7-sched-bfs-425.patch

This patch is only the 3.6 patch fixing any chunks that don't apply.

After that, I go through the incremental changes from mainline 3.6 to 3.7 to see any scheduler related changes that should be applied to BFS to 1. make it build with API changes in mainline and 2. benefit from any new features going into mainline that are relevant to the scheduler in general. I manually add the changes and end up with an incremental patch like this:

http://ck.kolivas.org/patches/bfs/3.0/3.7/incremental/bfs425-merge.patch
This patch is only merging 3.6->3.7 changes into BFS itself

Finally I actually apply any new changes to BFS since the last major release, bugfixes or improvements as the case may be, as per this patch here:
http://ck.kolivas.org/patches/bfs/3.0/3.7/incremental/bfs425-updates.patch

Git is an excellent source control tool, but provides me with almost nothing for this sort of process where a patch is synced up after 3 months of development. If I were to have my fork and then start merging all patches between 3.6 and 3.7, it would fail to merge new changes probably dozens and potentially hundreds of times along the way, each requiring manual correction. While merge conflicts are just as easy to resolve with git as they are with patch, they aren't actually easier, and instead of there being conflicts precisely once in the development process, there are likely many with this approach.

However git also does not provide me with any way to port new changes from mainline to the BFS patch itself. They still need to be applied manually, and if changes occur along the way between 3.6 stable through 3.7-rc unstable to 3.7 stable, each time a change occurs to mainline, the change needs to be done to BFS. Thus I end up reproducing all the bugfixes, moves, renames and back-outs that mainline does along the way, instead of just doing it once.

Hopefully this gives some insight into the process and why git is actually counter-productive to BFS syncing.

Enjoy 3.7 BFS.
お楽しみください

BFS related

Unfortunately my life remains in disarray with respect to dealing with my brother's issues.

However a couple of BFS related things came in my mail and I thought I'd share them.

One is graysky's performance comparison of current schedulers across various hardware in this comprehensive pdf:

cpu_schedulers_compared.pdf

The second is this rather cute set of T-shirts that Teb had made for himself and his girlfriend:

The vicissitudes of life

七転八起

I realise in this world there are people with far worse tragedies and far worse issues to deal with than my own so I've been reluctant to make a big deal of my own issues online, even though I have a mildly public persona. However I've been touched by the many warm wishes people have sent me over the last month when I mentioned that I had a family tragedy to deal with which was keeping me offline, despite the fact most of you did not even know what it was.

While I usually prefer to keep my private life separate from my online life, many of you have asked what it was that was so traumatic. Initially it was very difficult to talk about but now I find it somewhat helpful to speak about.

I'm from a family that has always been very close and I have two older brothers. On the Australian Father's day, 2nd September, my eldest brother George, who is the father of  two himself, was involved in a motor vehicle accident which gave him critical head injuries. Unfortunately he has been left with massive brain damage with very little prospect of recovery. He also had asked me many years previously to be his enduring power of attorney. Over the last month I have had to deal with the grief of his (effective) loss, been the medical contact for the family since I'm the only doctor in the family, deal with issues of choices to do with end-of-life decision making versus potential life in a vegetative state, support for various people affected by this tragedy, dealing with lawyers, financial institutions, credit card companies, utilities, gaining access to email, work authorities, insurance bodies and so on. The "system" does not seem well set up to take over someone's life if they're indefinitely incapacitated.

I don't really wish to go into any greater detail about this online, but suffice to say it has been the worst month of my life and I wouldn't wish this on my worst enemies.

And yes, my parents are still alive, and they are, without doubt, taking this the hardest.

The only good news, I guess, is that I'm working towards what I call the "new normal" in my life. I'll be hacking on BFS and -ck again fairly soon.

-ck

P.S. BFS and -ck for 3.6 is up in the usual place...

EDIT: Courtesy of  Matthias Kohler, this patch may fix boot issues if you have them:
http://ck.kolivas.org/patches/3.0/3.6/3.6-ck1/Fix%20boot%20issue%20with%20BFS%20and%20linux-3.6.patch

3.5-ck1, BFS 424 for linux-3.5

Thanks to those who have been providing interim patches porting BFS to linux 3.5 while I've been busy! Finally I found some downtime from my current coding contract work to port BFS and -ck to linux 3.5, and here is the announce below:

These are patches designed to improve system responsiveness and
interactivity with specific emphasis on the desktop, but suitable to
any commodity hardware workload.

Apply to 3.5.x:
http://ck.kolivas.org/patches/3.0/3.5/3.5-ck1/patch-3.5-ck1.bz2
or
http://ck.kolivas.org/patches/3.0/3.5/3.5-ck1/patch-3.5-ck1.lrz

Broken out tarball:
http://ck.kolivas.org/patches/3.0/3.5/3.5-ck1/3.5-ck1-broken-out.tar.bz2
or
http://ck.kolivas.org/patches/3.0/3.5/3.5-ck1/3.5-ck1-broken-out.tar.lrz

Discrete patches:
http://ck.kolivas.org/patches/3.0/3.5/3.5-ck1/patches/

Latest BFS by itself:
http://ck.kolivas.org/patches/bfs/3.5.0/3.5-sched-bfs-424.patch

Web:
http://kernel.kolivas.org

Code blog when I feel like it:
http://ck-hack.blogspot.com/


This is a resync from 3.4-ck3. However, the broken out tarballs above also 
include the upgradeable rwlocks patch, and a modification of the global 
runqueue in BFS to use the urwlocks. These are NOT applied in the -ck1 patch, 
but can be applied manually at the  end of the series as indicated by the 
series file. It is currently of no demonstrable performance advantage OR 
detriment in its current state, but is code for future development.

Enjoy!
お楽しみください

-- 
-ck