v4.7_0472_vrq3 patch is released
The new code changes have been in -test branch since 4.6 release and
tested by users since then, bugs has been fixed and improvement has been
added. Although currently -test branch is pending on user feedback for
further improvement, but IMO, these code changes now on the -test branch
are stable enough to be merged into the -vrq branch. So, here it comes the v4.7_0472_vrq3 patch.
This patch is identical with v4.7_0472_test2 except the version print out in dmesg. Comparing to -vrq2, the major feature in vrq3(-test2) is the introduction of preempt stick task to replace the original stick timeout in previous release, which helps with high workload performance and the result can be proved in the sanity test report.
Code has been pushed to bitbucket and github, all-in-one patch is also available.
Enjoy -vrq3, :)
I tested some more gaming and found out very gut test subject: Diablo3 (D3 further on). With D3 standard Ubuntu (4.4) and plain BFS (4.7) kernel behaves properly, but v4.7_0472_test2 and even 4.6.3 + test5 + debug2 (which behaves gut for other games) is heavily affected.
Unfortunately with D3 those 2 vrq/test versions are really bad, plain BFS can achieve 80 FPS on my HW, but with vrq/test it achieves 15 and stutters _A LOT_, mouse and screen micro freezes every second or so, I don't even have to go into game to play, even in starting screen mouse freezes (starting screen in D3 is 3D accelerated as well, there are some graphic effects rendering), in two words - it's very bad.
I don't know what is so different in D3 which causes such a stutters.
I suppose I'll compile "puzzle kernels" (3 patches on top of test2 and a whole day for compiling :)) and try them with D3.
Thanks for the feedback.
For D3 game issue, do you running it via wine or something like that? I have no idea what the difference in running D3 and other games, and how it is related to scheduler. But as the result is so obviously, it should be able to find out the first impact commit between plain BFS and -vrq by "git bisect". If you familiar with git and want to help with this issue, please let me know.
For the debug patches testing, I'd suggest you focus on other games rather than D3, especially the ones can tell the difference.
D3 is run via wine the same way as I test World of Tanks. That is wine staging + gallium 9 (direct3d 9 state tracker on linux, very low overhead). Actually most of the testing is done using World of Tanks, but due to illness I haven't played it for almost a month :)
I occasionally run some native games as well, but there is none at the moment I own and want to play.
About git, I have never bisected anything, but I'm afraid that bisecting will take so much time which I don't really have.
I'll tell You my setup and You say whether it's suitable for bisecting :)
So I have Ubuntu VM on a laptop where I compile my stuff, of course I have git and Your repo already checked out, there is about 30GB free space, compilation takes about 2 hrs or a bit more for one kernel build.
If I could somehow automate every kernel build, I can try to help.
FYI: Con just released BFS 480 which seems a big step forward.
For your setup, the disk space is not a problem. The compilation is a bit long even it is in a VM. So, do you enable kvm for your VM? Or do you consider move the kernel compilation to the iron machine, :)
I am looking at Con's 480 changes, the skiplist is most interesting part, I will workout a plan how to adapt my works upon 0480 later.
I do not plan to install all needed stuff for compilation onto host, for compilation I have specific VM.
I use VirtualBox and it says that I use "KVM paravirtualization".
I compile kernel with Ubuntu config, which means a lot of modules (approx 5K), maybe it's slow because of this.
To separate the build env from host env, I'd prefer a chroot setup which can provide nearly iron machine performance.
As there are big changes in bfs 0480, I have decided to roll all over ~60 commits upon BFS0480 again in a new branch and release check point tags when building up this branch. These tags can be used to trace potential issues maybe introduced by -vrq changes.(It's kind of a bisect, IMO)
Currently, issues want to be traced are
1. Intel cpu NMI hang issue @pf
2. Wine D3 low performance issue @Eduardo
I'll official announce in a new post when the first checkpoint tag in this branch is ready.
Thanks for wrriting thisReplyDelete