Wednesday, April 13, 2016

4.5 VRQ patch v4.5_0469_vrq0 released

Here comes the all in one vrq patch v4.5_0469_vrq0 which now is based on the latest BFS 0469, of course the new sched_interactive design in the latest BFS has been removed and be replaced by the task policy based caching timeout design in VRQ.

Basically, this release doesn't introduce much code changes comparing to the previous release, just put the code based on the latest BFS for better maintenance in the future.

As usual, I'm still waiting the upstream BFQ patch for 4.5 to update the GIT repositories. If you have any question/feedback about the VRQ patch, please let me know.

Have fun with this new release!

BR Alfred

Edit:
I have pushed the latest vrq0 code to my repository on bitbucket and github. Individual commit can be viewed now.

25 comments:

  1. Maybe it's just too early... but I cannot download this patch (although it appears in the repository).

    BR Manuel Krause

    ReplyDelete
    Replies
    1. Bad news. I can't download it neither. I have open a ticket to bitbucket, hopefully they have it fixed soon.

      Delete
    2. It works now, I have done nothing about it. Patch file can be download and no damage in it as I have checked. So, please go ahead, :)

      Delete
  2. @post-factum:
    A little off-topic on here, but...
    Have you had luck to boot a kernel with your current pf-4.5 TuxOnIce implementation?
    I've fetched the patch from your repo, when 4.5.0 was relatively fresh, but get a BUG at bootup with something like schedule while atomic. The call trace mentions schedule, schedule_bug, set_cpus_allowed_ptr and several toi_ functions before my disks get fully initialized.

    I hope, you can help a little,
    BR Manuel Krause

    ReplyDelete
    Replies
    1. https://github.com/NigelCunningham/tuxonice-kernel/issues/13

      Delete
    2. Btw, @Alfred, could you please also take some look at that bugreport? I've tried to dig into locking code, but besides one extra spinlock found nothing new in TOI code diff. Still have to wait for Nigel's response :(.

      Delete
    3. @post-factum: Thank you very much for letting me/ us know about your reports. I do get the same errors.

      I really hope for a fix (Nigel?!), as the 4.5 kernel is the second major kernel in a row that I cannot test. In 4.5 at least my gfx issues vanished.

      BR, Manuel Krause

      Delete
    4. I believe I've found the root of the issue, but as of now have no idea how to fix it.

      The description is under TOI ticket here: https://github.com/NigelCunningham/tuxonice-kernel/issues/13#issuecomment-210982607

      Delete
    5. Thank you for investigating this so deeply. And finally Nigel wrote a first reply ^^

      For now I've reverted the one commit in question -- and everything, including VRQ0, BFQ and TuxOnIce hibernation, seem to work reliably!
      Although I now get another call trace: http://paste.opensuse.org/44184299

      Best regards,
      Manuel Krause

      Delete
    6. Thanks for two of you to investigate the issue. Haven't checked email during last weekend.

      @post-factum
      I'd like to ask if the original BFQ 4.4.0-v7r11 works for kernel 4.5 or any other changes needed to make it works on 4.5. I ask this b/c I got about 3 seconds 50% workload kernel compile improvement in 4.5 comparing to 4.4, that's a huge improvement. Consider there is no huge code changes in scheduler code, and the only still missing patch is BFQ on my 4.5, I'd like to add BFQ in and rerun the tests.

      BR Alfred

      Delete
    7. Forward-ported BFQ runs well for me. In fact, this is what Paolo suggested for those who want BFQ for 4.5 before official release. So just merge and give it a try.

      Delete
    8. @post-factum
      I have seen your v4.5-pf1 released. Any feedback to the scheduler part? I'd like to add some new changes and release vrq1 soon.

      Delete
    9. @post-factum:
      Nigel's patch for 4.6.0-rc4 mainly only reflects our discussions' result. It's different and working, but not with my loop mounted file. It would have been too nice, wouldn't it?

      BR and thank you for your work and invested time!
      Manuel Krause

      Delete
    10. I guess the patch for 4.6-rc4 is broken as well because I see lock release, but not taking the lock... No idea, why that happens with TOI at all.

      Should the vanilla hibernation work for you?

      Delete
    11. I've noticed this, too. I've got too little knowledge to comment on it.

      The vanilla hibernation doesn't show any issue. Except for firefox getting usable again is terribly slow :-( but that's typical when not using TOI.

      BR Manuel Krause

      Delete
    12. @post-factum:
      I've now done the "dumb" job to forward-port my last known working TOI patch (for kernel 4.3.3) to apply and cleanly compile on kernel 4.5.2. I didn't bother with cosmetic changes or line offsets.
      No related compile warnings -- and now I can have a loop mounted ext4 file staying alive again, relevant for anyone who uses truecrypt or sth. like that.
      One thing remains: I get almost the same WARNING like in http://paste.opensuse.org/44184299 on the first hibernation.

      I've uploaded the "ported" patch to http://workupload.com/file/TFFm8Ka
      so someone with knowledge can review and judge the changes, that make current TOI failing.

      BR Manuel Krause

      Delete
  3. @Alfred, no issues reported against scheduler AFAIK. All my 3 nodes work OK as well.

    No doubt, I'm ready to merge and test vrq1 as well.

    ReplyDelete
    Replies
    1. @Alfred:
      My machine is also running fine, regarding the scheduler, with almost the same patches' setup that post-factum uses. I, in fact, only leave the UKSM out.

      The only problems arise from the missing love and care for the TuxOnIce patch during the last months.
      With the omitted TOI commit (mentioned above, && see post-factum's repo) -- what I need to omit to boot the 4.5 kernel at all -- I get a failing hibernation, whenever a file is loop-mounted on top of a partition. In my first case it was a truecrypt file on top of an ext4 partition, but I also verified that it happens with pure ext4 files loop-mounted on ext4 partitions as well.

      Btw., I'm also looking forward to your ongoing "future" work on VRQ!

      BR Manuel Krause

      Delete
    2. @post-factum @Manuel
      It's not huge/new feature for VRQ, just a continuous improvement for the "sticky task". In short, I'm trying *not* putting sticky task into grq, to avoid grq locking conflict. The test result looks pretty good for 2 of my pc/laptop, and I will release a -test branch for testing once it's tested on my old notebook tonight.

      BR Alfred

      Delete
    3. Updates:
      The new code just *not* booting my old notebook, I have found the cause and trying to solve it in a proper way. I have to forecast the test branch release at this weekend.

      BR Alfred

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

    ReplyDelete
  5. Alfred, one of my users reported this panic while suspending his machine with vrq:

    http://ix.io/xoe

    Reverting vrq fixes the issue for him. Ideas?

    ReplyDelete
    Replies
    1. @post-factum
      From the call trace, it looks not related to scheduler code and panic at putty low level spinlock functionality.
      BFS/VRQ does modified the cpu hot-plug code as register callback when suspend/resume but it works well. Anyway I'd double check those logic as well.

      Does the user use 4.4 pf kernel as well and has same issue with 4.4 kernel?

      BR Alfred

      Delete
    2. It was reported that the issue occurs even without VRQ. So, nvm.

      Delete