Monday, 3 March 2014

BFS 0.446, 3.13-ck1

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:
3.13-sched-bfs-446.patch

CK branded BFS:
3.13-ck1


Apologies for the delay, but I simply swamped with my other projects, interests and work.


Enjoy!
お楽しみください

46 comments:

  1. No need to apologize we understand. Thank you for still doing this.

    ReplyDelete
  2. Big Thanks for your work Con.

    PS: Hope, that your Bitcoins weren't in Mt.Gox.

    ReplyDelete
    Replies
    1. Luckily I used Gox as an exchange only and not a bank. I'm more a cold storage kind of guy.

      Delete
  3. Many thanks, Con, seems to work for me, will test a bit more.

    However, I'd like to suggest two patches again:

    https://gist.github.com/pfactum/9332896

    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.

    ReplyDelete
    Replies
    1. Damnit, how do I keep forgetting these? Thanks, and sorry.

      Delete
    2. I ran into this issue with kernel 3.13.6. I'll give these patches a try.

      Delete
    3. 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
  4. 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.
    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,

    Manuel Krause

    ReplyDelete
    Replies
    1. BFS is unchanged from the last kernel so you need to look for other causes.

      Delete
    2. Yes, @ck, merci, I didn't want to bother you. BTW, THX for the new patches.

      Maybe the other people on this blog do know something related.

      Manuel Krause

      Delete
    3. 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.

      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!

      Delete
    4. 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?

      cu sysitos

      Delete
    5. First of all: The problems have gone away && thank you very much for your replies!
      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

      Delete
    6. 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. :-((

      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:
      https://bugs.archlinux.org/task/39005
      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,
      Manuel Krause

      Delete
    7. - @kernel 3.15.x
      + @kernel 3.13.x
      Manuel Krause

      Delete
    8. Hi Manuel,

      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)

      cu sysitos

      Delete
    9. @Mike / sysitos: Do you know/have seen what kernel process hangs? May be a way to investigate further.

      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

      Delete
    10. Hi 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?
      Thanks.

      CU sysitos

      Delete
    11. Hi Manuel,

      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 ;) )

      CU sysitos

      Delete
  5. Con, it seems that BFS breaks KVM on 3.13 :(. Here is what I get on KVM loading with BFS enabled:

    https://gist.github.com/9344714

    With BFS disabled everything works OK.

    Here is my config:

    https://gist.github.com/9344717

    Any ideas?

    ReplyDelete
    Replies
    1. 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
    2. Meanwhile, I'm really not the only one guy faced this issue. Will investigate more as well.

      Delete
    3. It seems that this is another upstream bug unhidden by BFS.

      https://bugzilla.redhat.com/show_bug.cgi?id=1038929

      The fix suggested is to use 1 vCPU per KVM guest. Will try it ASAP.

      Delete
    4. This merge fixes the issue:

      https://github.com/pfactum/pf-kernel/commit/f0010a3a9e45165b0fdb14b76d6054550b60c534

      WTH?..

      Delete
    5. Thanks. Looks pretty clear it's a mainline bug to me. It basically should be an unconditional schedule instead of conditional.

      Delete
    6. How could we explain why unconditional schedule should be there without involving BFS to report this bug to kernel bugzilla :)?

      Delete
    7. 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:
      http://ck.kolivas.org/crap/kvm-fix.patch

      Delete
    8. kvm_resched() has been wiped out in 3.14.

      Delete
    9. ck's patch works in here under Arch.
      Thanks.

      Delete
  6. This comment has been removed by the author.

    ReplyDelete
  7. 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
  8. tell me its possible to use new bfs version with old kernel like 3.10?

    ReplyDelete
    Replies
    1. Just use the one for 3.10? I dont think theres too many changes between versions, just resyncs

      Delete
    2. 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
  9. 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.

    https://bitbucket.org/alfredchen/linux-gc/commits/ccd24d561143257279f3f9a8a256c456f7af1b9d/raw/

    My dead-lock fix based on BFS patch.

    https://bitbucket.org/alfredchen/linux-gc/commits/ac3f3602a9b24ec27f3d0bcb1b383bf3d07fbf2d/raw/

    ReplyDelete
    Replies
    1. Couple of patches on top of yours:

      1) https://gist.github.com/10118357
      2) https://gist.github.com/10118375
      3) https://gist.github.com/10118384

      First one fixes compiling with CONFIG_SMP=n.
      Second fixes Kconfig deps.
      Third fixes KVM with BFS enabled.

      Delete
    2. Thanks to both of you ! =)

      Delete
    3. 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
    4. 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
    5. Yep, faced the issue today again, and here are photos:

      https://dl.dropboxusercontent.com/u/7541592/2014425101142.jpg

      https://dl.dropboxusercontent.com/u/7541592/2014425101157.jpg

      It took ~15 secs to open dmesg, then I was unable even to reboot the machine.

      Delete
  10. Having a problem there with ck-patched 3.13.9 (not under ck-patched 3.12 and not under plain 3.13)
    shutdown -h does not switch the GPU (here a blob-driven nvidia 9800GT) off.

    ReplyDelete
    Replies
    1. OK, apparently a trivial timing problem, as :
      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...

      Delete
  11. Working on new BFS at last. Hopefully something to post soon.

    ReplyDelete
    Replies
    1. 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.
      http://www.change.org/ru/%D0%BF%D0%B5%D1%82%D0%B8%D1%86%D0%B8%D0%B8/canonical-redhat-novell-add-alternative-linux-kernels-with-perfomance-patches-into-repositories

      Delete