Monday, February 15, 2016

VRQ v4.4_0466_vrq3 released

In this minor update, just two new commits

88a07b9 bfs/vrq: Do not cache rt tasks
23c7b29 bfs/vrq: Add policy_stick_timeout
7d189bb bfs/vrq: -vrq version bump to v4.4_0466_vrq3 

Just three commits, so I don't provide the all-in-one patch file, you can find the new tag(v4.4_0466_vrq3) in bitbucket and github repository, and the linux-4.4.y-vrq branch also been updated.

For the cached task, now they have a stick timeout which set to 1/16 ms rather than using the same cache timeout value in previous version. Based on my test, which help the system resume delay and also help to overall performance. And because of this new changes, I have set the NORMAL policy task caching timeout to 6ms. Please re-test this default setting again and see how it works in this new version.

BR Alfred

15 comments:

  1. @Alfred:
    You're back again! :-))) Hope, you had good times!

    I've applied these two commits on top of my cumulative v4.4_vrq2 patch for the 4.3 kernel (see last thread), as I still dislike using unusable 4.4. I took care, that the timings are now @ your current default values (having used NORMAL_POLICY_CACHED_WAITTIME 1 or later 2 with kernel 4.3).

    My experience:
    + interactivity of KDE desktop is better than with my previous 4.3 even with heavy disk i/o
    * in the first 2 hours I saw frame drops or audio stuttering in mpv without any reason
    * I cannot reproduce it after 6h of runtime (seldom, that things get better with uptime)
    + no other regressions observed

    These commits seem to be good adjustments.

    Thank you very much for your hard work,

    BR Manuel Krause

    ReplyDelete
    Replies
    1. @Manuel
      Thanks for testing and sharing. Finial I can call it stable and move on. :)

      BR Alfred

      Delete
    2. @Alfred:
      Sorry for disturbing your enthusiasm. Can you please find a little time to have a look at my last cumulative vrq2 patch for 4.3 mentioned above from the previous thread and verify, that it's o.k.? Does it include _all_ improvements and/or does it introduce failures _of mine_ ?
      Unless you say that it's o.k., I still remain with doubts, allthough it's working, even with your latest commits on top.

      Thank you in advance,
      BR Manuel Krause

      Delete
    3. @Manuel
      Be confidence. If the code works for you then most likely it has no problem for your use case, :)
      I don't have time check the code line by line, I will find some time to see if the 4.4.1 works for my chromebook, if not, I'll port 4.4.x-vrq to 4.3.y and update the 4.3 branch this weekend.

      BR Alfred

      Delete
    4. @Alfred:
      What should I say... Of course I want to see your official backport...

      And they've published 4.4.2, including fixes for your tpm_tis according to the changelog! So maybe your issue is fixed.
      Related to my 4.4.x issues, there's still no fix in it.

      BR Manuel Krause

      Delete
    5. @Manuel
      Thanks for the info. Just rebased and tested with 4.4.2, it solved the tpm_tis issue for me. So, save my time to back-port 4.4.y-vrq to 4.3 and considering 4.4 is a LTS release, I am thinking about make linux-4.4.y-vrq the first LTS branch too.

      BR Alfred

      Delete
    6. @Alfred:
      That's a little sad (no backport^^). And good -- to know your issue is fixed.
      Mine isn't in 4.4.2 -- maybe in 4.5 (reading the bugzillas).
      I've already tried to backport some i915 4.5 fixes for 4.4, but it's still not sufficient. And as I'm not a programmer I'd better abandon this trial now.

      So, I'm not able to test your patches with 4.4.

      BR Manuel Krause

      Delete
  2. Is there a complete patch file yet?

    ReplyDelete
  3. Hello,
    How do I merge this to the kernel source?
    Regards

    ReplyDelete
    Replies
    1. All my code changes are in bitbucket https://bitbucket.org/alfredchen/linux-gc or github https://github.com/cchalpha/linux-gc , you can simply get the codes with git.

      BR Alfred

      Delete
  4. Hi Alfred,

    until now I used the zen Kernel with BFS. Nevermind, Con ins't the fastest one to update the BFS code for kernel 4.4 ;), so I tested your VRQ kernel (don't know the difference to the GC branch, but used the VRQ because it's already in 4.4).
    So what should I say now, I 'm very impressed. Kernel starts fine, runs fine, suspend does work, doesn't see until now any problem. And most important (for me), there are really nice load values near 0!! Haven't seen this with BFS for ages now. With BFS I got the avg load form 0,15 .. 0,30 under KDE with firefox (many tabs open ;) ) and some other (idle) apps open. With VRQ same is under 0,01 .. 0,05 with my I7 cpu. The CPU freq is jumping often (don't know if this is correct), but the CPU temp stays low, what is more important for me.
    Under high load the and high disk io, playing a HD video is smooth, no sticking. And even the the samba network speed is higher (but don't know, if the 4.4 kernel is the cause).

    So at all, thanks so far. Fine work.
    I fetched the kernel from bitbucket, branch vrq is still at 4.4.1.
    Are you planing to sync your changes in time with the actual 4.4.x kernel, or should I merge it manually?
    Maybe you are so friendly and could me explain, what's the difference between -gc and -vrq and the vanilla kernel (or Zen -> BFS, BFQ, AUFS).

    Thanks and keep up the good work.

    Regards sysitos

    ReplyDelete
    Replies
    1. @Mike
      Thanks for your testing and sharing your experience.
      If you want to look deep into what's the difference between vrq and original bfs, you can check my previous posts, I have tried my best to explain the major features adding into VRQ, and wish that would help to understand the code changes when you look into the codes.

      There is some minor pending modification upon vrq3, but not major enough to bump up to vrq4, so I haven't updated the branches yet, it's still on 4.4.1, but vrq3 are good enough to apply upon 4.4.3.

      BR Alfred

      Delete
  5. Hi Alfred,

    thanks for reply. Running now your patches vrq2 and vrq3 on top of zen kernel 4.4.6. Only a minimal change was necessary. And it's running fine. Plasma5 is eating sometimes CPU power after suspend, but this only means that GC patches aren't solving KDE5 bugs ;) But compared to vanilla kernel, it doesn't happened so often. Fine work. Thanks.

    Regards sysitos

    ReplyDelete