Monday, May 6, 2019

BMQ 0.94 release

BMQ 0.94 is released with the following changes

1. Sync up with mainline kernel scheduler code changes.

This is the first BMQ release for 5.1 kernel, it just contains the sync up changes.

Enjoy BMQ 0.94 for v5.1 kernel, :)

Full kernel tree repository can be found at https://gitlab.com/alfredchen/linux-bmq
And all-in-one patch can be found at gitlab.

Please report bugs at https://gitlab.com/alfredchen/bmq/issues.

UPDATE:
Pls check https://gitlab.com/alfredchen/bmq/issues/5 for detail, in short, pls pick up commit https://gitlab.com/alfredchen/linux-bmq/commit/c98f44724fac5c2b42d831f0ad986008420d13c2 for this release.

19 comments:

  1. Panics shortly after the boot: https://gitlab.com/alfredchen/bmq/issues/5

    ReplyDelete
    Replies
    1. Umm, technically, this is not the panic, but oops, but the system freezes immediately after that.

      Delete
    2. I can not confirm this behavior at this point. I have a build with Ubuntu mainline config + nohz_full + 100Hz + disabled UKSM. This time build is from Your git repo.
      It boots and works fine on Ryzen@home (at least 5 reboots) + light gaming.

      Will test on i7@work, will report back, if something goes south :)

      BR, Eduardo

      Delete
    3. @pf
      Just a quick test for you. Pls revert sync commit https://gitlab.com/alfredchen/linux-bmq/commit/14102e7208bf621e574877d66d6f8d5b5d7e7c74 and see if it helps.

      Delete
    4. same problem, i try later compile with https://gitlab.com/alfredchen/linux-bmq/commit/14102e7208bf621e574877d66d6f8d5b5d7e7c74

      Delete
    5. @Alfred Chen, now i compiled with revert patch and my pc now work stability

      Delete
    6. I'm trying to reproduce it on a VM, but so far I couldn't.

      Will check things on a laptop again, and then will check the revert too.

      Delete
    7. OK, I just had to try harder ☺.

      https://gist.github.com/pfactum/04f6940ddd7c06b56664b35320b868b8

      (this is without revert)

      Will now test revert.

      Delete
    8. OK, revert seems to help, at least, so far. I'll leave it burning for a longer time, though.

      For future tests, here is my reproducer: https://gitlab.com/post-factum/burn_scheduler

      Once the revert is applied, it doesn't crash (well, it does, but in the UKSM code, which is a known issue I have to address somehow, but that's, likely, completely unrelated).

      The revert is strange, though. How making things non-atomic is supposed to fix things? Do you have an explanation why this commit is harmful?

      Delete
    9. @pf
      Will wait for long test result then officially revert the commit as a solution ATM.
      This commit was the last commit I synced from 5.1 mainline but I also noticed BMQ and CFQ are different in affected code path, and worried about that this may not work in BMQ for a second. Unfortunately, the commit doesn't make any side effect in my machines, so it is in this release.
      I think some affected code path is uncovered in current sync commit, I need to take closer look at it sometime in this this kernel release cycle, and may need your help to test the the new patch, as you are the likely one to have the machine and config can reproduce it, :). Before that, reverting the sync up commit should be a good solution, it worked before, and it will works.

      Delete
    10. It didn't explode even after the longer test. Looks good to me.

      Delete
    11. Pls check https://gitlab.com/alfredchen/bmq/issues/5 for detail, in short, pls pick up commit https://gitlab.com/alfredchen/linux-bmq/commit/c98f44724fac5c2b42d831f0ad986008420d13c2 for this release.

      Delete
  2. I installed the same kernel in i7@work, boots fine. Lets see whether it works as well :)
    Is this bug specific to some kernel config option or I'm just lucky as it does not seem to affect me so far?
    BR, Eduardo

    ReplyDelete
  3. @Alfred
    The same as Sveinar in 0.93 version, I have strange "hickups" in 0.94 (they were present in 0.93 version as well). On seemingly idle system things seem to freeze for a little (0.2-2 sec), for instance audio playback via old wine player, which is the most easily to notice because that's continuous stream, not something that can be overlooked, rarely firefox does not respond right away, but a second later it's fine.
    My observation is that even sitting and reading PDF, there are pauses in audio playback, but when computer is more busy, those things do not happen. For instance youtube in firefox have not had this issue, large documents or java programs do not lead to crackling sound as it was before. I don't know how this relates to scheduling and I don't want to guess much, but to me it seems that when scheduler has not much to do, these happen. Dunno.

    BR, Eduardo

    ReplyDelete
    Replies
    1. @Alfred, now I tried to switch yield_type to 0, for 30 minutes no issues, let's see what other effects it has, but so far, it's plausible.
      I will post results after more testing.
      BR, Eduardo

      Delete
  4. seems to work pretty well, but i have a very strange issue, pulse audio seems to be messed up, sound works, but the levels are all messed up, some sounds being too loud other being too quiet, very strange, doesn't happen on the stock kernel. I really have no idea why bmq would cause this problem its very strange.

    ReplyDelete
  5. @Oleksandr Natalenko and BMQ users:
    I hope that I'm allowed to post this slightly offtopic question here... as it regards one commit from your recent -pf kernel(s). Namely it's the "cpu-5.1: add a CONFIG option that sets -O3", "CONFIG_CC_OPTIMIZE_HARDER", (7fef9301).
    What would you say, is it a risky option? Or, do you have positive/ negative feedback already, regarding this option from your pf-kernel users community?

    TIA for your answer, best regards,
    Manuel

    ReplyDelete
    Replies
    1. From my experience O3 makes the kernel slower than O2.

      Delete