The changes to BFS include a resync from BFS 0.428, updated to work with changes from the latest mainline kernel, and numerous CPU accounting improvements courtesy of Olivier Langlois
(thanks again!).

For those who tried the -ck1 release candidate patch I posted, this patch is unchanged. The only issue that showed up was a mostly cosmetic quirk with not being able to change the CPU accounting type, even though it appears you should be able to. BFS mandates high res IRQ accounting so there is no point trying to change it.

Lately my VPS provider (rapidxen) has been nothing short of appalling with incredible amounts of downtime, packet loss and IP changes without notification. They also repeatedly send me abuse complaints that I have to respond to for my software being (falsely) tagged as viruses. Luckily I have a move planned in the near future - including where and how - when time permits, but if you find my server doesn't respond, apologies.

Enjoy!
お楽しみください

EDIT: There were some fairly dramatic CPU offline code changes to mainline (YET AGAIN!) and the changes to BFS to make it work were fairly significant so there may once again be issues with power off/reboot/suspend/hibernate. It gets tiresome watching the same code being rehashed in many different ways... "because this time we'll do it right".

You are a very astute reader. I edited my blog post with the following explanation as well as unlocked it to anonymous posters (here comes the spam).

"Note for those of you really paying attention: Both benchmarks used `make -j9 ...` even though the 3770k is a quad (4 physical + 4 virtual=8). I am aware that it is recommended NOT to use the x+1 formula for kernels running the BFS but felt that in order to fairly compare both schedulers, this needed to be held constant. That said, I have done some experiments where I varied the make flags (8, 9, 10) and found that there was no statistically significant difference on the BFS."

Also I don't have any time accounting issues any more as with previous BFS patch releases. But this could have been a bug of 'make oldconfig': I just learned this method is broken when upgrading major kernel releases!

A big warning: Use 'make defconfig' instead after a major kernel release! Greetings and many thanks from Hamburg, GermanyRalph Ulrich

Con, graysky has found out that increasing tick rate from 300 Hz to 1 kHz eliminates hanging on reboot. Could that be useful for fixing the issue properly and could you explain why it behaves so… unpredictably?

Graysky that is MOST interesting - assuming he really is running a vanilla kernel. As has been the case before, BFS may simply be more likely to bring out mainline bugs due to its design expressing race conditions more easily.

As you see 4294967295 value is abnormal. Same report came from another user:

===There is a problem though, now after hibernate-resume vmstat often displays 4294967295 (0xFFFFFFFF) as the first value (The number of runnable processes), in addition to normal values like 0, 1, etc.. So the kernel gives wrong process statistics. (I couldn't catch this bogus value in /proc/stat where it supposedly comes from, though. Probably because each time I looked at the file the process that I used for this was counted as runnable by the kernel, thus resetting the number of runnable processes to zero.)

I definitely don't observe this behaviour before hibernation. And I don't remember having this issue at the times of older kernels (3.5? 3.2?) when hibernation was usable to me.===

Right about now, about the only thing that would help me is another coder since I'm having trouble scheduling in time for BFS due primarily to real life commitments and less so other code distractions. I keep hoping for more time but it seems I only have less time with each kernel release.

Regarding the RCU boosting, I've made good experiences with the following:[CONFIG_TINY_PREEMPT_RCU=y is appropriate for my uniprocessor/-core system, btw.]CONFIG_RCU_BOOST=yCONFIG_RCU_BOOST_PRIO=99 <-- making it realtimeCONFIG_RCU_BOOST_DELAY=331 <-- using a prime number to avoid reoccurrences, smaller than default=500

Manuel,NO_HZ is proposed to spare energy: When idle do no more irq wakeups. But I do instead:- no NO_HZ- CONFIG_HZ_1000 down to CONFIG_HZ_300This also safes energy when idle 70 percentage and without the problems of NO_HZ set. And - unsure about - it provides a better throughput on highload, because the less irq context switches !?

Isn't a possible intervention of 300 times a second enough for me as user? I mean, even case of playing games? The unreasonable high 1000 Hz was introduced because of worst case experience of waiting times of over a second. But this prevents BFS as the scheduler!

I set CONFIG_RCU_BOOST_PRIO=18 , which results a process rcub/0 with prio -19. I need this lower abs number than the process irq/21-b43 with prio -51, because I have seen my wify connection got unreliable otherwise. Manuel, htop shows with push F6 and select sorting column your system priorities.

thanks for remembering me of CONFIG_HZ_300. I know, you've proposed this some months or even a year or more ago. Dunno, why I've abandonned that setting. But what I definitely remember is I got better scores in WCG (www.worldcommunitygrid.org) with CONFIG_HZ_300.

I completely don't understand your second paragraph beginning with "Isn't a possible...".

But currently I'm running a 3.9.4 with my optimizations and your 300 Hz. Let's see.

BTW: My htop (openSUSE 12.3) seems to have problems, that top doesn't show up: Orphaned processes that display, but that really aren't running any more. Maybe htop is dead? Or at least unusable?!

It's the old give some and get some topic. Interactivity for throughput in I/O or vice versa. The 300 Hz don't make ALL things better on my old system, it stays old. The same is valid for the BFQ I/O scheduler. You need to test it for yourself. For now we even don't have a 'Responsiveness-Benchmark' so far, what is a real shame!

@post-factum:Thank you for providing your work to us. Can you, please, provide a more detailed description of what it does before I use it (on the page and in a in-tree readme) and why you call it "silly".

Just to let you know that I tested your BFS patch v0.430 during a couple of weeks, but had to revert to a vanilla kernel because BFS causes mencoder to deadlock when using multiple cores to encode some videos (about 1 in 3 videos)...

No, no log message, just mencoder stopping dead in its encoding and sitting there, using 0% CPU forever. It was always during the second pass of a 2 passes encoding (VBR).And no, I'm not using any other kernel patch, just the vanilla Linux kernel...