A development blog of what Con Kolivas is doing with code at the moment with the emphasis on linux kernel, BFS and -ck.

Tuesday, 3 July 2012

BFS 424, linux-3.4-ck3

As seen on this blog previously, a bug showed up in 3.4-ck2/BFS 423 to do with unplugged I/O management that would lead to severe stalls/hangs. I'm releasing BFS 424 officially and upgrading 3.4-ck2 to 3.4-ck3, incorporating just this one change.

So I'm canceling this test at 78h of stable uptime.The most unresponsive application was firefox after 3 days running. After closing and restarting with the very same tabs it was snappy again.I definitely need to unlearn to blame the CPU scheduler first when things get slow.

It's been about two years since last I slapped your BFS on a kernel. It has come a long way. The responsiveness and stability of 424 is incredible. Thank you much for doing the hard work, you perennial underdog you. (-;

Linux-3.4.6-bfs runs stable here. NO_HZ can save some 3percent energy using HZ_1000, but down to HZ_300 it is only a third of that. And it this NO_HZ full of bugs - see the fixes every now and then. Having a fine tuned config you should not feel any difference as a user using only 300 HZ. Did you once manual saved the times for running athletes at school: Measuerd any difference of 2 thousands of a second? Overall troughput should be better using only HZ_300.

The ckN-patches should define more reasonable values:---# CONFIG_NO_HZ is not set...CONFIG_HZ_300=y# CONFIG_HZ_1000 is not setCONFIG_HZ=300...# RCU Subsystem#CONFIG_TREE_PREEMPT_RCU=yCONFIG_PREEMPT_RCU=yCONFIG_RCU_FANOUT=64# CONFIG_RCU_FANOUT_EXACT is not set# CONFIG_TREE_RCU_TRACE is not setCONFIG_RCU_BOOST=yCONFIG_RCU_BOOST_PRIO=14CONFIG_RCU_BOOST_DELAY=440---Setting CONFIG_RCU_BOOST_PRIO higher results in a kernel task rcun having -15 priority (minus plus one!?). This is a workaround for me having no more overflow of process times.

Putting CONFIG_RCU_BOOST_DELAY a ten percent down result in general lesser latency even when using the mainline CFScheduler.Ralph Ulrich

Hmm, wait wait... Con says CONFIG_HZ_1000 is better for desktop use (responsivity), you say CONFIG_HZ_300 is better for troughput and one "should not feel any difference" using 300. Debian uses 250. Aptosid 1000. Now I'm confused...

just an observation from my side. i am not sure if it is BFS or mainline, and why I didn't observe it previously with incremental patches, but yesterday I rebuilt 3.4.6 with patch-3.4-ck3 and i had a build issue on one of the machines. The laptop has CONFIG_NO_HZ for reasons of battery life, and i needed to comment out the following lines in include/linux/sched.h (from line 2028):

Untested but since bfs uses the old global load calculation I don't see why it wouldn't work unless I forgot something else. Basically just making it compile should be good enough since I'm fairly certain it doesn't use any of the new stuff although with something as complicated as the linux kernel shit sometimes happens.

I have to say your article inspires me to the most, it is so instructive to tell others how to understand that in such a special view.I will share your articles with my friends, i think they will like them just like me. What's more, can you update them more frequently? I am a fan of online games. rs gold , runescape gold