Announcing a resync and update of BFS for linux kernel 3.13.x:
Apart from build fixes and synchronisation with new kernel changes, this is only trivially different to BFS 444. A build failure on 445, along with a desire to release only even numbers, prompted version 446.
BFS by itself:
CK branded BFS:
Apologies for the delay, but I simply swamped with my other projects, interests and work.
No need to apologize we understand. Thank you for still doing this.ReplyDelete
Big Thanks for your work Con.ReplyDelete
PS: Hope, that your Bitcoins weren't in Mt.Gox.
Luckily I used Gox as an exchange only and not a bank. I'm more a cold storage kind of guy.Delete
Many thanks, Con, seems to work for me, will test a bit more.ReplyDelete
However, I'd like to suggest two patches again:
The first one should fix compiling with CONFIG_SMP=n, the second one should add more restrictions on kernel configuration. Please, take a look at both of them.
Damnit, how do I keep forgetting these? Thanks, and sorry.Delete
I ran into this issue with kernel 3.13.6. I'll give these patches a try.Delete
I tried the patches, and they worked. It compiled fine. I also want to let you know, Con, that I appreciate your work. I compiled kernel 3.14 with just the standard Gentoo patchset, and I realized just how slow my desktop system is without using your patches. Of course, I'm also running an aging system with an AMD Athlon XP 1.8 GHz which is slow by today's standards. So I need to squeeze out all the performance I can. :-)Delete
I get weird temperatures and abrupt 100% fan actions with vanilla 3.13.5 with this CK and most recent BFQ at my HP Notebook.ReplyDelete
In gkrellm the highest T had been @74°C, so far (3.12.13), and is now growing to 94°C. Then, the fan goes to 100% for 10~30secs cooling it to approx. 82°C.
That is not good, if I compare 74 to 94 °C.
Have I missed a .CONFIG option for 3.13, especially?
Please leave a hint,
BFS is unchanged from the last kernel so you need to look for other causes.Delete
Yes, @ck, merci, I didn't want to bother you. BTW, THX for the new patches.Delete
Maybe the other people on this blog do know something related.
Can't reproduce that here. 3.13.5+bfs+bfq+tuxonice working very, very well, and temps are exactly the same as with 3.12 bfs+bfq+tuxonice.Delete
it's not a notebook, but still.
CPU Fan: 986 RPM (min = 600 RPM)
HDD Fan: 1042 RPM (min = 600 RPM)
Rear Fan: 762 RPM (min = 600 RPM)
CPU Temp: +36.0°C (high = +60.0°C, crit = +95.0°C)
MB Temp: +32.0°C (high = +45.0°C, crit = +95.0°C)
194 Temperature_Celsius 0x0022 119 108 000 Old_age Always - 31
194 Temperature_Celsius 0x0022 030 041 000 Old_age Always - 30 (0 16 0 0)
(ambient temp 23C)
Btw, awesome work Con, thank you!
No problem here with temperature and fan, so the only problem I see with 3.13.5 (Zen kernel and stock Opensuse kernel) is a value >1 of load average in idle (regardless if cfs or bfs is active) for my i7. With 3.12 I had values of 0.05 in idle. This is valid only for my i7, the atom cpu and the AMD cpu do not have these high load problem on 3.13.5. Anyone similiar experience?Delete
First of all: The problems have gone away && thank you very much for your replies!Delete
Mmmh... but it's like looking for a needle in a haystack: I haven't bothered removing -CK from the kernel, as you others had no problems. I have changed some CONFIGs (back to no hierarchichal scheduling in BFQ, to no Intel P-State, which wasn't appropriate for my CPU already before, and some unrelated ones) and had a look at the actual stable-queue pending patches for the next 3.13.6 to pick up 11 patches from these 172 (atm of writing) that sounded to (may) have anything to do with my machine&setup. Recompiled freshly and now everything appears to be in a good shape again.
So, a trial of a conclusion: It's either fixed by the changed CONFIGs or it'll be fixed with 3.13.6 or... 3.13.5+CK+BFQ doesn't like ODD compile numbers like #1 ;-D
Best regards, thank you, Manuel Krause
O.K., I've now retested without -CK/BFS, as my success message above was a false positive. And additionally it did not survive a suspend-to-disk. :-((Delete
It has _nothing_ to do with BFS/-CK !!! (Maybe, the FAIL is only triggered earlier.) This one is really OFF-TOPIC.
Seems, the cooling related things (maybe 'policies' or whatever) get kind of 'hardcoded' with each booting @kernel 3.15.x, and not changed with CPU load changes.
If I did a suspend-to-ram in a hot situation and come back, it'll keep a fan speed above normal. (What is nice, as no overheating may occur in the following time; but you see, that if it's coded to no CPU usage, e.g. after 6h of shutdown and restarted then, it leads to non-acceptable temperatures and abrupt 100%-cooling-fan actions (maybe emergency measures of my system) -- same as reported in my first message.
The only valuable reference, so far, f**king g**gle, was the following:
As I'm not @ that list, and I get this FAILURE, too, with openSUSE, what should I do?
Thanks for any reply and best regards to you,
- @kernel 3.15.xDelete
+ @kernel 3.13.x
so use the 3.12 kernel, it should be a longterm kernel.
My problem with high average load values result from a hung kernel process, starting with kernel 3.13 and exist still in the 3.14(RC5). No clue, what's the problem. (Different .configs tested, even the failsafe kernel does not work)
@Mike / sysitos: Do you know/have seen what kernel process hangs? May be a way to investigate further.Delete
For now, I've reported it with some of the text above to linux-kernel && linux-pm. It's their job, too, to avoid melting plastics. ^^
And: Yes, I'm back to 3.12.13+CK2+BFQv7r2.
Best regards, Manuel
Tried the perf tools, but couldn't find any information, Maybe, because I don't know, what I am doing ;).
Is here anybody out there, who could help me do identify the cause of my problem?
so, in time with 3.14 and after looong searching and testing I found the cause for my hung kernel process. Replaced on my laptop my DVD drive with a second hdd and this breaks some acpi processes for newer kernels (maybe DELL Bios isn't the best one too).
So with boot parameter "acpi_sci=low" (don't think, that anybody else is using this ;) ) -> I don't get processes in "D state" anymore, my average load is under 1 again. Haven't seen any drawbacks yet.
Nice, that I'm back on new kernels (must only wait on Con's BFS ;) )
Con, it seems that BFS breaks KVM on 3.13 :(. Here is what I get on KVM loading with BFS enabled:ReplyDelete
With BFS disabled everything works OK.
Here is my config:
No idea offhand since the BFS code is unchanged, I'll have to go looking to see if some change from the mainline merge was required that I missed.Delete
Meanwhile, I'm really not the only one guy faced this issue. Will investigate more as well.Delete
It seems that this is another upstream bug unhidden by BFS.Delete
The fix suggested is to use 1 vCPU per KVM guest. Will try it ASAP.
This merge fixes the issue:Delete
Thanks. Looks pretty clear it's a mainline bug to me. It basically should be an unconditional schedule instead of conditional.Delete
How could we explain why unconditional schedule should be there without involving BFS to report this bug to kernel bugzilla :)?Delete
Well it says it needs resched and then goes on to only do a conditional resched only. In which case this patch may be enough:Delete
kvm_resched() has been wiped out in 3.14.Delete
ck's patch works in here under Arch.Delete
This comment has been removed by the author.ReplyDelete
Con, nothing to do with linux kernel, BFS and -ck. My name is Chris and I used to work at Amazon. I was just thinking about how your Kindle's were having issues and I helped you get replacements for them. I almost got into a tiny bit of trouble, but when my manager asked the all important question of "Did you do what you think was right for the customer?" I was able to say yes, I think I did. I hope they are still working well. Cheers!ReplyDelete
tell me its possible to use new bfs version with old kernel like 3.10?ReplyDelete
Just use the one for 3.10? I dont think theres too many changes between versions, just resyncsDelete
It's just re-syncs for newer kernels. CK2 happened for 3.12 because patches were required, but no special new features as such.Delete
For those who want try BFS on 3.14 kernel before CK's official release, I have ported 0.446 to 3.14 and run for 5 days. All looks good. Haven't tried suspend yet. Just FYI.ReplyDelete
My dead-lock fix based on BFS patch.
Couple of patches on top of yours:Delete
First one fixes compiling with CONFIG_SMP=n.
Second fixes Kconfig deps.
Third fixes KVM with BFS enabled.
Thanks to both of you ! =)Delete
Not the end of the story. Kernel tends to hang with CPU being stuck after thawing from hibernation with BFS enabled. Will investigate more whether it is BFS or TuxOnIce bug again.Delete
Tested with suspend and it works. Hibernation is always another story, but I haven't used hibernation setup, so if you have some log, I can look into and see if I missed sth during merge.Delete
Yep, faced the issue today again, and here are photos:Delete
It took ~15 secs to open dmesg, then I was unable even to reboot the machine.
Having a problem there with ck-patched 3.13.9 (not under ck-patched 3.12 and not under plain 3.13)ReplyDelete
shutdown -h does not switch the GPU (here a blob-driven nvidia 9800GT) off.
OK, apparently a trivial timing problem, as :Delete
Increasing CONFIG_DEFAULT_MESSAGE_RUNLEVEL from 4 to 5 makes the problem less systematic (1/2) from 5 to 6 (1/5) and from 6 to 7 not reproduceable.
BTW... This cannot stand for a valid workaround...
Working on new BFS at last. Hopefully something to post soon.ReplyDelete
Hello! after i tried kernel with BFS, i will never go back again. I think every linux user shout try it. That is why i have made this petition.Delete
Very Much Appreciated.
Working With Computers Is Fun Again.