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!
お楽しみください

Posted by at
Labels: , ,

45 comments:

  1. CS18 November 2013 at 22:11

    Thank you!

    ReplyDelete
  2. Unknown18 November 2013 at 23:59

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

    ReplyDelete
  3. Anonymous19 November 2013 at 00:06

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

    ReplyDelete
    Replies
    1. graysky23 November 2013 at 02:14

      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
  4. Anonymous19 November 2013 at 04:02

    finnaly suspend working :D
    it's patch day :D

    ReplyDelete
  5. Unknown19 November 2013 at 04:43

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

    ReplyDelete
  6. Anonymous19 November 2013 at 10:10

    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. Anonymous19 November 2013 at 10:36

      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. ck19 November 2013 at 11:07

      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. Anonymous19 November 2013 at 11:41

      @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. ck19 November 2013 at 11:44

      Did you try vanilla 3.12.0 ?

      Delete
    5. Anonymous20 November 2013 at 04:57

      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. Anonymous21 November 2013 at 03:21

      (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. Mike22 November 2013 at 03:29

      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. Anonymous22 November 2013 at 07:42

      (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. Anonymous22 November 2013 at 07:45

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

      Delete
    10. Anonymous22 November 2013 at 08:03

      (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. Anonymous22 November 2013 at 08:35

      @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. ck22 November 2013 at 08:58

      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. Anonymous23 November 2013 at 05:20

      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
  7. Andre R.19 November 2013 at 16:50

    Thank you for this project!

    ReplyDelete
  8. Oleksandr Natalenko20 November 2013 at 21:58

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

    ReplyDelete
    Replies
    1. Oleksandr Natalenko24 November 2013 at 09:45

      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. Anonymous24 November 2013 at 09:58

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

      Delete
    3. ck24 November 2013 at 10:06

      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. Oleksandr Natalenko24 November 2013 at 10:30

      @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. ck24 November 2013 at 10:32

      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. Oleksandr Natalenko24 November 2013 at 10:34

      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. Mike24 November 2013 at 12:28

      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. ck24 November 2013 at 12:31

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

      Delete
    9. Oleksandr Natalenko24 November 2013 at 20:24

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

      Delete
    10. Oleksandr Natalenko24 November 2013 at 20:44

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

      Delete
    11. Oleksandr Natalenko26 November 2013 at 05:16

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

      Delete
    12. ck26 November 2013 at 09:28

      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
  9. Anonymous20 November 2013 at 22:32

    it wont compile on most recent 3.12 kernel...

    ReplyDelete
    Replies
    1. Anonymous22 November 2013 at 02:35

      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. Anonymous22 November 2013 at 03:06

      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. Anonymous22 November 2013 at 05:53

      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. Anonymous22 November 2013 at 05:57

      @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. Anonymous22 November 2013 at 06:38

      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. Anonymous22 November 2013 at 06:46

      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. Anonymous22 November 2013 at 07:26

      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
  10. Unknown21 November 2013 at 05:06

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

    ReplyDelete
    Replies
    1. graysky21 November 2013 at 07:39

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

      Delete
  11. Anonymous27 November 2013 at 09:42

    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

Subscribe to: Post Comments (Atom)