Monday 18 November 2013

BFS 0.443, 3.12-ck1

Announcing a resync and update of the BFS CPU scheduler for linux-3.12


BFS by itself:
http://ck.kolivas.org/patches/bfs/3.0/3.12/3.12-sched-bfs-443.patch


CK branded BFS:
http://ck.kolivas.org/patches/3.0/3.12/3.12-ck1/


Apologies for the delays. I've been swamped by other projects (o.k. I lie, mainly just cgminer). The changes in this new version, apart from the obvious resync with mainline, are some timing fixes courtesy of Olivier Langlois (Thanks!) and a concerted effort to make suspend to RAM/resume work properly.


Enjoy!
お楽しみください

45 comments:

  1. thx for the release, but resuming from hibernation(suspend to disk) is still broken.

    ReplyDelete
  2. Thank you graysky, one of the best news to day :) Hope that 3.12 is soon in repo-ck

    ReplyDelete
    Replies
    1. I like to be thanked but I had nothing to do with this release... if you're thanking me for updating the Arch kernel packages in repo-ck then you are welcome :)

      Delete
  3. finnaly suspend working :D
    it's patch day :D

    ReplyDelete
  4. Did somebody test suspend to disk on a multicore system with this patch ?

    ReplyDelete
  5. This one is broken. Maybe my original openSUSE 3.12.0 kernel packages or BFS. First resume from hibernate didn't let me into re-login, while the rest was loaded (ssen in console). Resuming took ages(!!!) compared to 3.11.8.
    And then, copying files to /dev/shm with more than enough swap almost stalled the system (unresponsive for minutes).

    Manuel Krause

    ReplyDelete
    Replies
    1. Second trial, no KDE re-login possible after resume from hibernation. This time with cma disabled (had been new to me last time, above). {Posting from my 3.11.8}

      Not amused, regarding the "concerted effort", :-(
      Manuel Krause

      Delete
    2. Not amused eh? I guess you get what you pay for :(

      The concerted effort was for suspend to ram and resume, not hibernation to disk. No idea about that.

      Delete
    3. @ck:
      Didn't want to offend you. Sorry, if my words sounded like that.
      But I think there's going on something weird with 3.12.0 & CK1.

      Manuel Krause

      Delete
    4. Did you try vanilla 3.12.0 ?

      Delete
    5. Again, my apologies! I appreciate your work on BFS/CK!
      Just some preliminary info from this afternoon's testing: Without the ck1-patch the openSUSE-3.12.0 (ge8fa6b4) kernel-source failed in the same way to resume from hibernation.
      Now I have two choices to investigate further: use the openSUSE kernel-source-vanilla package, that is made without openSUSE addon stuff, or remove the still (as usual) applied BFQ-patches.

      Best regards, Manuel Krause

      Delete
    6. (1) Plain vanilla openSUSE source rpm is working with hibernate/resume from out of KDE.
      (2) Scaring thing that may have occurred with all my 3.12.0 testing before, it looses ttyS0 when resumed, with "ttyS0: LSR safety check engaged!" in dmesg. That is my Trackman Marble @COM1 serial port. I never got this message before (prior to 3.12). And reconnecting it, what worked with 3.11.x, fails. But that effect in conjunction to my normally deactivated touchpad made me think that the Xserver has died (in my posting above).

      So, please, tell us, how can we be helpful? You have my email address.

      Best regards, Manuel

      Delete
    7. Hi,

      using the new BFS on 3.12.1 ZEN kernel on OpenSuse 13.1. Suspend and hibernate do work both. Ok, must be fair, I must remove the suspend package (s2disk, s2ram etc) and using systemd to suspend/hibernate (e.g. with systemctl hibernate). Now its working fine.

      So thanks Con.
      cu sysitos

      Delete
    8. (3) plain vanilla 3.12.0 + BFQ (no BFS/CK) patches works, as well, with hibernate+resume. The serial mouse is still M.I.A. there.
      Manuel

      Delete
    9. (4) plain vanilla 3.12.1 + BFQ + CK1 survived a suspend-to-ram with serial mouse alive!
      Manuel

      Delete
    10. (5) plain vanilla 3.12.1 + BFQ + CK1 survived a suspend-to disk but now serial mouse died again. PS/2 touchpad keeps working. So, it's a 3.12. kernel (suspend-to-disk) issue?
      Manuel

      Delete
    11. @ck: Quite a question to you, to apply brute force... Can't you, maybe, adjust the the patch segments that resulted in "suspend-to-ram" to work, in a simple way --> for "suspend-to-disk" to work, too?
      Best regards, Manuel

      Delete
    12. Suspend to ram is a completely different process to suspend to disk. I didn't touch any code directly that affects suspend to disk but the scheduler is involved in everything that happens everywhere in different ways. The answer then is no, it doesn't work that way.

      Delete
    13. Just to "draw a final stroke" under this sub-thread's first sentences with my conclusions: Going to the vanilla kernel sources provided by openSUSE, without their added stuff, prevented having problems with heavy shm/swap usage. To be honest, CFS also produces hiccups in this scenario. Also, hibernate+resume _do_ work, the mentioned issues are _not_ BFS/CK1 related!

      And another weird thing I found out by coincidence today, leading this here to get even more offtopic:
      (1) hibernate+resume looses my serial trackball - also with pure vanilla - no way to get it back
      (2) a following suspend-to-ram+resume, alone, didn't reactivate it:
      (3) then issuing in a root konsole "setserial -a /dev/ttyS0" -- that only reads out the config -- does reactivate the trackball ! All configs from xorg.conf are there
      (4) PS/2 touchpad is not affected at all
      (5) it's fully reproducible in the sequence written

      If anyone has a clue to this... I would be thankful !
      Best regards, Manuel Krause

      Delete
  6. Unfortunately, BFS for 3.12 kernel completely breaks hibernation for me :(. Vanilla works OK.

    ReplyDelete
    Replies
    1. It seems that

      ls -1 /proc | egrep -e '[0-9]+' | sort -n | xargs -I {} taskset -pc 0 {}

      cures hibernation with BFS enabled. Interesting.

      Delete
    2. Can you, please, be so kind to explain, what that command would/should do?!
      Thanks, Manuel Krause

      Delete
    3. That is interesting because the scheduler does that before suspending to ram automatically. Perhaps somehow in BFS it doesn't do it before suspending to disk. Will investigate some time in the next year when time permits :\

      Delete
    4. @Manuel Krause: this command pins all processes to first CPU core.

      @ck: nevertheless, sometimes this trick doesn't help :(. It would be great to see some fix from you.

      Delete
    5. If it doesn't help then that's not the issue. I can't provide a fix for something I don't know the cause of and don't have the time to investigate...

      Delete
    6. I guess it *sometimes* doesn't help, because after executing that command new processes may spawn by something else, and those processes could be placed on non-zero CPU.

      Delete
    7. What about the kernel config parameter BOOTPARAM_HOTPLUG_CPU0? It's for my config NO and hibernation does work here. But maybe the init system (systemd for me) has some influence too.

      cu sysitos

      Delete
    8. That should never be enabled with BFS. I thought I made it so you could NOT enable it in BFS.

      Delete
    9. You could enable it with BFS as I have got one in my config :/. Will try to disable and test again.

      Delete
    10. Unfortunately, it didn't help. The system hibernates, then after powering it on again image is read and system hangs.

      Delete
    11. The most interesting thing is that TuxOnIce+BFS works, and vanilla+BFS doesn't. Possible mainstream bug unhiding detected?

      Delete
    12. Weird, and possible that it's a mainstream bug only unmasked by BFS (since it's not the first time this would have happened), but my general rule is if something's broken with my code applied, then it's almost certainly my fault.

      Delete
  7. it wont compile on most recent 3.12 kernel...

    ReplyDelete
    Replies
    1. Bfs does not compile anything.
      gcc-4.7 compiled my linux-3.12.1 - patched with bfs-443 perfectly! And runs well. Thank you very much, Con!

      Ralph Ulrich, greetings from Hamburg.

      PS: Manuel, if you want to discuss open a thread at phoronix? I know, Chen posted there in the forums also.

      Delete
    2. He/she most probably wanted to express, that the kernel has not been compiled with BFS patches applied. Without error messages we won't know what went wrong.

      @Ralph: Would you mind uploading your working kernel .config file? You can find mine here: http://pastebin.com/t9FUA56B (I'm sorry that I haven't thrown out a lot of the usual and unneeded openSUSE config options, so far.)

      Best regards, Manuel Krause

      Delete
    3. Hi Manuel, myconf:

      http://paste.opensuse.org/57295471
      It is used for an 3 years old AppleMacMini, intel coreDuo.
      All of Amd I disabled and many more: I just need 20 Min to compile.

      @Manuel, I asked you to open a forum thread, because this blog feedback hasn't all the features (code tags etc). I we don't come to a conclusion, we then might ask here a question.
      Ralph Ulrich

      Delete
    4. @Manuel, forgot to say: I don't use hibernation. I haven't tested:
      Gentoo~unstable, kde-4.11.3, systemd-208, nvidia-331.20, gcc-4.7.3
      Ralph

      Delete
    5. Sorry, Ralph, that I didn't react to your encouragement to open a forum thread, so far. Currently, I need to catch the "golden thread" through my previous testing, maybe I did sth. wrong. If the newly compiled +ck1 +bfq 3.12.1 vanilla openSUSE also fails, ...
      Let's see and exercise a little patience.
      Manuel Krause

      Delete
    6. Keep away from Bfq patches: Far too complicated - I stay with deadline for IO, which ever had good test results at phoronix.
      Ralph

      Delete
    7. BFQ has always (before 3.12, at least) been a good companion for disk performance, without any bad interference with BFS/CK. I don't see yet, why you consider it "far too complicated."
      Manuel

      Delete
  8. I finaly got a full backtrace of the hibernate resume hang.
    http://imgur.com/mQT0FVV

    ReplyDelete
    Replies
    1. No idea about the backtrace, but your BIOS is out of date. Version 1903 was released on 2013.09.16.

      Delete
  9. Please, guys&gals, keep on looking at the first page: Con searches for people with working suspend-to-ram and still failing suspend-to-disk for his experimental test patch:
    http://ck-hack.blogspot.de/2013/11/experimental-hibernation-patch-for-bfs.html?showComment=1385504880963#c56698966828730126

    I really want to encourage you,
    Manuel Krause

    ReplyDelete