88a07b9 bfs/vrq: Do not cache rt tasks
23c7b29 bfs/vrq: Add policy_stick_timeout
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
@Alfred:
ReplyDeleteYou'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
@Manuel
DeleteThanks for testing and sharing. Finial I can call it stable and move on. :)
BR Alfred
@Alfred:
DeleteSorry 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
@Manuel
DeleteBe 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
@Alfred:
DeleteWhat 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
@Manuel
DeleteThanks 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
@Alfred:
DeleteThat'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
Booted OK for me.
ReplyDeleteIs there a complete patch file yet?
ReplyDeleteHello,
ReplyDeleteHow do I merge this to the kernel source?
Regards
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.
DeleteBR Alfred
Ok. Thank You.
DeleteHi Alfred,
ReplyDeleteuntil 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
@Mike
DeleteThanks 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
Hi Alfred,
ReplyDeletethanks 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