A development blog of what Con Kolivas is doing with code at the moment with the emphasis on linux kernel, MuQSS, BFS and -ck.
Thursday, 17 March 2011
2.6.38 and BFS/-ck releases
2.6.38 came out faster than I was expecting, and I've made no effort as of yet to port BFS or -ck to it. It looked like there were still bug reports on the last -rc on the linux kernel mailing list so I wasn't expecting the "stable" release to come out yet. Furthermore, I've been working very hard on the next major release of lrzip which is a massive rewrite so that has completely occupied my time and I am not done with it yet. So there will likely be quite some delay before I can release an official BFS/CK for 2.6.38. I also would like to watch what fallout, if any, there is from the autogrouping code and decide what I should do with respect to that feature. I'm sure some unofficial BFS ports will be available soon enough but obviously I won't be able to say with any confidence whether they can be trusted or not.
Subscribe to: Post Comments (Atom)
Please keep up your very good work on your BFS/-ck patchset(s)!ReplyDelete
I do really miss them since I wanted to test new efforts within Mesa/radeon/Gallium3D and so kept sticked to plain kernels without BFS/-ck. BFQ isn't ready for 2.6.38, as of today, too. I found it to be a good companion to your patches -- reducing I/O bound timeouts to the display.
I too would like to say keep up the good work, as it's very much appreciated.ReplyDelete
So I will test in the meantime ulatencd, better than nothing with 2.6.38 ;). The zen team does some porting of BFS to actual kernels, but this Kernel does not support for me suspending, so its not usable. So I hope on your patches :-)ReplyDelete
Btw, the branch names for lrzip sound interesting.
"I've made no effort as of yet to port BFS or -ck to it."ReplyDelete
SLACKER! heh heh
Without bfs running 2.6.38 , I wonder why I don't have any latency issues any more. This is not the 200 lines cgroup thing but something more since vanilla-2.6.36 (I left out 2.6.37 because 2.6.38_rc1 was stable at the beginning, not much new came into the kernel after chrismas, only rcu work).ReplyDelete
There was big difference to better when patching bfs into 2.6.36. You felt this without any testing. I am curious if even 2.6.38 will be better with bfs. Perhaps only measurable but not any more feelable?
i completely agree with ralph. latency has improved a lot in 2.6.38.ReplyDelete
There have been a number of VM and writeback changes that went into 2.6.38, and perhaps they're responsible.ReplyDelete
I'm testing ulatencyd, and felt no improvement over the vanilla kernel. This version is really impressive to me. When the BFS arrives I'm goint teste here!ReplyDelete
But I'm only a user who knows almost nothing about the kernel, and my tests are, zip a BIG folder with lrzip whith -z option plus video playback (HD) plus music and web browser, start up, those things. If I feel an improvement I use the current version, and since 2.6.34 kernel version I do not feel an improvement.
brilliant work on this mate, thanks not only for the tangible benefit we've seen thus far with BFS, but for the light your patchset has brought to the need for desktop interactivity on the linux desktop, and the pressure it's put on upstream to compete and pay attention to this, instead of trying to optimize scheduling for headless half million CPU systems. Even if the answer/implementation by upstream trying to meet this need is insufficient, the attention is GOOD imho. I'm sticking with BFS until I see a compelling reason otherwise, and can't wait to see your work folding it into the .38 tree when available. Thanks again, and as time permits, keep up the good work! --cach0rr0ReplyDelete
2.6.38 seems like a buggy disaster here. The system just freezes as soon as I go fullscreen with an application. If not, the desktop will render erratic graphics (windows that shouldn't be there any longer, etc.)ReplyDelete