v4.6_0470_test5 patch released
v4.6_0470_test5 patch is available which fix a bug in the last two test patches(test3 and test4), so it's highly recommended to upgrade to this test5 patch if you are on test branch.
PS, it's not include the debug patch for Eduardo, I'm still waiting for the feedback then decide how to tune the codes.
BR Alfred
Got some weird crash in alx driver (Gigabit Ethernet) with 4.4-vrq3. Even netconsole is empty because the network crashed.
ReplyDeleteI doubt that is the issue I'm looking for as the stacktrace I observed was something different than usual. Also, alx crashed for me several times before.
So, dunno...
@Alfred: Maybe fixing the font size of your posting would get back readability?! ;-)
ReplyDeleteUnfortunately, yesterday I have upgraded my Firefox-ESR to the most recent major version. As I see, it has even more performance issues than the predecessor -- I hope to tame it over time by adjusting the tunables that I can investigate.
These facts make any comparison to previous releases of VRQ/testN in my usual "everyday's use" completely useless for me.
I've then compiled the current test5 and am running it since then, as a new starting point for future comparisons.
Please, keep pushing out your improvement patches. :-)
@post-factum:
Thank you very much for your continued testing. I really appreciate your endurance!
BR to all of you contributors,
Manuel Krause
@pf
DeleteYou may have another kind of issue in alx driver, if it crashed, your netconsole log can be generated.
It should be good to move to 4.5 and remember to build kernel locally, I need to reference to the mixed assemble file and the netconsole to located where the code is stopping.
@Manuel
Thanks for testing. You can compare test5 vs -vrq branch, comparing test5 to previous test patch is pointless, :)
BR Alfred
@Alfred,
Deletefinally I got to testing. The results are like this: with 4.5-bfs and 4.6.3-bfs (both include BFQ as the rest) no issues for hours of testing, vrq - occasionally there are micro stutters, test4 + debug1 and test4 + debug2 are tricky, I can not distinguish them easily. Stutters appear from time to time, sometimes 3 in a row, but my very subjective "gut feeling" says that debug2 is slightly better.
So, if I have to order them from better to worse, it's gonna be 1. BFS, 2. VRQ, 3. debug2, 4. debug1, 5. test3.
regards
Eduardo
@Eduardo
DeleteAs test5 patch fix a task caching issue, so please test it and test5+debug[0,1,2], compare them to BFS and -vrq.
BR Alfred
@Eduardo:
DeleteThank you very-very much for your testing time!!!
@Alfred:
At the moment I'm a bit confused -- or name it "I'm investigating" -- on how the "new" FF ESR distributes system resources, including CPU time. It's completely different to my last FF ESR major release (that was updatable til my last message).
Still uncompared with any previous VRQ on here, I only want to say that the -test5 behaves very well or better than -test4. Response times on the KDE desktop seem to have decreased after heavy /dev/shm usage with resulting heavy swapping (to second disk). Since weeks this got really better now.
I don't understand why you don't provide the debug patches to me, too. You have my email-address. With the "new" Firefox I experience frame drops in flash content playback too, but unfortunately this can also be caused by the remote server "not serving" in time. Last night there was a nice connection, but it was hard to count after how many seconds the stuttering occurs and re-occurs and if there was a pattern at all. I'd say, too many unpredictable side-parameters that I can't influence.
BR to all of you,
Manuel Krause
@Manuel
DeleteAll the debug patches are based upon the latest test patch, to help me understand how to tune the cache/stick behaviours in scheduler, in -test branch. These patches are not common necessary for all user as not everyone is sensitive for these changes, including me, but I think Eduardo's hardware environment and usage cases are sensitive.
For your issue, you need to identify which introduce the issue, by software(FF or X component) upgrade? By kernel upgrade(4.5->4.6, not scheduler related), or BFS upgrade/VRQ upgrade/test branch patch related? Only if the issue is introduced by -test branch, these debug patches may help. Otherwise, there should be no point to try the debug patches.
BR Alfred
@Alfred,
Deleteyesterday I was able to test plain test5 and I'm glad to say that it's about vrq level or even better when playing - stutter happened very occasionally in game, but sometimes when computer becomes less busy (out of battle in the chat room), stutters appear more often.
Does it still makes sense to run it through debug0? I'll try 1 and 2 when I have time.
br,
Eduardo
@Eduardo
DeleteGlad to know the fix code in test5 works as expected.
Please try debug1 and debug2 when you are free.
BR Alfred
I'm extremely disappointed about FF ESR 45.2.0's performance, at first. Unfortunately I cannot revert to the previous ESR (and should not, for safety reasons).
DeleteRegarding system updates, the XOrg stayed the same for some weeks on here now.
What Eduardo says about "stuttering, when system is less busy" -- I can confirm it with -test5 on here. This can happen after/ while video playback without mouse movement. It seems like the system takes a (noticeable) break before getting back to normal interactivity. Result is a lagging mouse pointer at first and other windows' refreshes needing some "warm-up" time.
This was happening before, too. New FF changes all experience (to the negative).
I don't have the endurance to newly test _all_ the senseful test patterns you've proposed.
BR, in the hope, that this little info is helpful, too,
Manuel Krause
@Alfred,
Deleteyesterday I did some testing on test5 + debug1/2.
My gut feeling appeared to be wrong, debug1 did a _lot_ better than debug2. With debug2 the situation was about the same as plain test5, but debug1 made all the difference. I was testing for an about a hour or so and notice stutter once or maybe twice which might not even be related to scheduler, in fact I'm inclined to think that was unrelated to kernel at all.
Sure, I'll do more testing some time and will get back to You! Also I'll try it on laptop to see how it affects the battery life.
Anyhow, it appears that work started in debug1 is the way to go :)
Thanks Alfred!
@Manuel,
testing time is rather ok as testing & gaming goes hand in hand in this particular case, compilation takes quite a time (1.5hrs for one build) :)
As this made a difference and might be beneficial to You as well, I can send You my kernel build (.deb's) or patch and/or config, please ask if You need them.
But as Alfred said, it might not help Your system, even his system is not affected and I don't see any stutters in my day-to-day standard computer usage in office (which does not involve games) either, so ymmv ;)
br,
Eduardo
@Eduardo
DeleteThanks for testing. Your conclusion is met my expectation. The debug1 patch which disable stick/caching for NORMAL policy tasks, which improve interactivity mostly. The debug2 patch, which just disable stick for NORMAL policy tasks, caching is still working. Next, would you please try to tune NORMAL_POLICY_CACHED_WAITTIME in bfs.c based on test5 + debug2, it is default 5, I'd suggest your to try it from 1 to 4.
BR Alfred
@Alfred,
Deletewhat You're basically saying is that I should go for test5 + debug2 and tweak NORMAL_POLICY_CACHED_WAITTIME to, let's say, 3?
Can I go for test5 + tweak only or You know for sure that it won't help?
br,
Eduardo
@Eduardo
DeleteWe knows that in debug1 patch, disabled both sticky and caching helps. The debug2 patch disabled "sticky" task for NORMAL policy tasks, so we can see if tweak the caching timeout to a lower level helps or not.
BR Alfred
@Eduardo:
DeleteThank you for your offers. At the moment I don't know wheter it's better to either wait for Alfred's regression fix or test the debug2 patch as well (with the proposed tuning values) to get a second experience.
If you have time you can upload the debug2 patch to sth. like pastebin and post the link here.
BR, and good luck to Alfred for his regression analysis,
Manuel Krause
I have upload these 2 debug patches to download page of bitbucket. You can give it a try.
DeleteBR Alfred
@Alfred:
DeleteThank you for providing the patches publicly! :-)
I've now started testing "in the midlle" with debug2 on top of test5 and NORMAL_POLICY_CACHED_WAITTIME (4). I don't see advantages or disadvantages vs. standard test5 (for the first 2h uptime). ;-) Needs more testing time, of course, and then maybe lowering the tunable even more.
BR, Manuel Krause
Mmmh, setting NORMAL_POLICY_CACHED_WAITTIME to (2) doesn't change much on here vs. (4).
DeleteNow trying debug1 patch upon standard test5.
BR, Manuel Krause
O.k., for this decision I don't need too many minutes of uptime: debug1 is much more interactive for my system, from the bootup til using KDE and other programs, than every previously used revision of VRQ.
DeleteBR, I'm enjoying it :-)))
Manuel Krause
Along with Afred's suggestions, I felt the need to revert to an older version of XOrg + drivers, from which I usually saved a copy on disk from time to time, before doing major updates from openSUSE's repository.
DeleteThe now re-installed version of this repo, from 20160320 (! March !), does NOT show mouse/ -wheel timeouts, as I've reported before in some other blog comment.
But I definitely don't know whom to report this issue.
Any advice appreciated.
At the moment I'm still with 4.6.4 + VRQ2 test5 + debug1 + BFQ for 4.5. And it's running fine.
BR, Manuel Krause
@Alfred,
DeleteI tested Your suggestion, I did test5 + debug2 and NORMAL_POLICY_CACHED_WAITTIME set to 2. At first I wanted to set it to 3 (middle ground) but I finally decided on 2 because I wanted to see whether that helps at all.
And, yes, it did help! I tested for 30-40 minutes and not a single stutter. I specifically did not update the system so I can compare apples to apples.
I'll try 3 at some point as well unless You suggest another plan.
Thanks and br,
Eduardo
@Alfred:
DeleteWhat setting of NORMAL_POLICY_CACHED_WAITTIME with debug2 patch would come next to the version of debug1 patch with default settings, meaning, from your progammer's view and from your performance testing results? I'm currently running the setting of (1). The lower I set this value -- the less (positive) impact it has. Never tested (0) so far.
What we chase, is somekind of a "break-even-point", am I right?
BR, Manuel Krause
@Manuel
DeleteWhat's next on -test branch is now the third priority item on my list. First two are 4.7 sync-up and regression fix. Based on users feedback and testing result at that point, should be easier to make a choice. So, having fun with 4.6 kernel and wait for the 4.7-testing, :)
BR Alfred
@Alfred, OK, I got v4.5 plus .7 stable patch plus -vrq0 from here (https://cchalpha.blogspot.com/2016/04/45-vrq-patch-v450469vrq0-released.html). Also, I've disabled SMT.
ReplyDeleteCompiling locally now and will test ASAP.