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!
お楽しみください
Posted by at
Labels: , ,

47 comments:

  1. sir_lucjan4 March 2014 at 01:23

    Thank you!

    ReplyDelete
  2. Anonymous4 March 2014 at 03:20

    Thank you!

    ReplyDelete
  3. Marc Grondin4 March 2014 at 05:12

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

    ReplyDelete
  4. Mike4 March 2014 at 05:55

    Big Thanks for your work Con.

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

    ReplyDelete
    Replies
    1. ck4 March 2014 at 12:24

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

      Delete
  5. Oleksandr Natalenko4 March 2014 at 06:37

    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. ck4 March 2014 at 15:45

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

      Delete
    2. Anonymous1 April 2014 at 08:36

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

      Delete
    3. Anonymous13 April 2014 at 15:27

      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
  6. Anonymous4 March 2014 at 12:07

    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. ck4 March 2014 at 12:24

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

      Delete
    2. Anonymous4 March 2014 at 12:52

      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. Anonymous4 March 2014 at 22:01

      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. Mike5 March 2014 at 05:10

      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. Anonymous5 March 2014 at 09:10

      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. Anonymous7 March 2014 at 07:50

      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. Anonymous7 March 2014 at 08:55

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

      Delete
    8. Mike8 March 2014 at 06:35

      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. Anonymous8 March 2014 at 06:53

      @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. Mike10 March 2014 at 08:13

      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. Mike9 April 2014 at 06:45

      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
  7. Oleksandr Natalenko4 March 2014 at 22:26

    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. ck7 March 2014 at 10:36

      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. Oleksandr Natalenko7 March 2014 at 17:45

      Meanwhile, I'm really not the only one guy faced this issue. Will investigate more as well.

      Delete
    3. Oleksandr Natalenko8 March 2014 at 10:05

      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. Oleksandr Natalenko8 March 2014 at 22:25

      This merge fixes the issue:

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

      WTH?..

      Delete
    5. ck8 March 2014 at 22:28

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

      Delete
    6. Oleksandr Natalenko8 March 2014 at 23:28

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

      Delete
    7. ck9 March 2014 at 10:13

      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. Oleksandr Natalenko9 March 2014 at 19:12

      kvm_resched() has been wiped out in 3.14.

      Delete
    9. Adam Dagan26 March 2014 at 18:45

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

      Delete
  8. Adam Dagan26 March 2014 at 18:08

    This comment has been removed by the author.

    ReplyDelete
  9. Chris Kittinger31 March 2014 at 08:11

    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
  10. Unknown5 April 2014 at 06:50

    tell me its possible to use new bfs version with old kernel like 3.10?

    ReplyDelete
    Replies
    1. anon5 April 2014 at 09:11

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

      Delete
    2. Anonymous9 April 2014 at 00:36

      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
  11. Alfred Chen8 April 2014 at 12:39

    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. Oleksandr Natalenko8 April 2014 at 22:48

      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. kernelOfTruth19 April 2014 at 05:25

      Thanks to both of you ! =)

      Delete
    3. Oleksandr Natalenko19 April 2014 at 19:02

      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. Alfred Chen25 April 2014 at 15:45

      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. Oleksandr Natalenko25 April 2014 at 17:21

      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
  12. aCOSwt29 April 2014 at 19:35

    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. aCOSwt1 May 2014 at 08:31

      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
  13. ck6 May 2014 at 17:32

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

    ReplyDelete
    Replies
    1. Unknown13 June 2014 at 02:04

      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
  14. Anonymous24 December 2014 at 01:21

    Thank You.
    Very Much Appreciated.
    Working With Computers Is Fun Again.

    ReplyDelete

Subscribe to: Post Comments (Atom)