VRQ 0.89f release
Normally I won't do two release in a day, but there are always exception. Here is the VRQ 0.89f relase with just one single commit
Rewrite the best_mask_cpu(). Which now use sched_cpu_affinity_chk_masks, to provide better performance improvement and to avoid addtional checking in non smt abilty cpu but has SMT kernel config enabled.
In short, in my sanity test, it shows improvement in all kinds of workload, here comes the sanity result of VRQ 0.89f before the next kernel release.
vrq0.89f
>>>>>50% workload
>>>>>round 1
real 5m27.812s
user 10m13.565s
sys 0m39.533s
>>>>>round 2
real 5m27.771s
user 10m13.407s
sys 0m39.521s
>>>>>round 3
real 5m27.834s
user 10m13.448s
sys 0m39.579s
>>>>>100% workload
>>>>>round 1
real 2m54.660s
user 10m30.269s
sys 0m41.142s
>>>>>round 2
real 2m54.602s
user 10m30.652s
sys 0m41.021s
>>>>>300% workload
>>>>>round 1
real 2m57.899s
user 10m40.231s
sys 0m41.864s
>>>>>round 2
real 2m57.682s
user 10m40.238s
sys 0m41.928s
>>>>>round 3
real 2m57.480s
user 10m40.219s
sys 0m41.282s
Enjoy this final vrq release before next kernel, :)
code are available at
https://bitbucket.org/alfredchen/linux-gc/commits/branch/linux-4.8.y-test
and also
https://github.com/cchalpha/linux-gc/commits/linux-4.8.y-test
All-in-one patch is available too.
BR Alfred
@Alfred,
ReplyDeleteI have encountered strange behaviour using this version on my new HW, after some time or suspend or smth, CPU locks itself into some frequency, for instance yesterday it locked itself to 1.7GHz, no more, I can do whatever about changing it, I tried performance, tried to set 2.2GHz etc., but it does not go any higher than 1.7. Now it's stuck to 1.2GHz, which, again, is very strange and I'm not able to increase the freq. Temperatures are in check so it must be not HW throttling.
After restart - all fine until smth happens.
I'll try using different kernel now, but previously I have not encountered such things neither with MUX nor standard, but I admit I have not used this machine extensively, hopefully it's not HW glitch.
I keep You updated with my findings.
Do anyone else encounter this type of thing?
Br, Eduardo
@Eduardo
DeletePlease check what cpufreq driver you are using on you new HW? The intel p-state driver is reported broken.
@Alfred,
Deletemy commandline: kernel: [ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.8.12-vrq root=UUID= ro pcie_aspm=force intel_pstate=disable i915.enable_guc_loading=2 i915.enable_guc_submission=2 quiet splash vt.handoff=7
And I was a bit imprecise about frequency locking, what I meant was that it will not go higher than some frequency, it just impose some limit by itself.
VRQ was 4.8.12-vrq, now running 4.8.11-mux, is it broken in 4.8.12 ?
Br, Eduardo
@Eduardo
DeletePlease check cpufreq related information under /sys/devices/system/cpu/cpu*/cpufreq/
Repost the eaten reply by the stupid blog system
Delete>@Alfred,
>
>I tested 89f version w/ 4.8.14 kernel and there are no more stuck frequency problems, it seems that 4.8.12 was to blame.
>Tests are, as usual, on google page, I haven't tested D3 yet, but will do soon if You would like to see the results.
>
>Br, Eduardo
Hi. New benchmarks of VRQ0.89f, still using acpi-cpufreq+ondemand.
ReplyDeletehttp://openbenchmarking.org/result/1612072-TA-CFSVSVRQ891
SQLite performance is better. There is quite a big regression in 'John the Ripper', and a smaller one in pgbench.
Here is the kernel config (based on archlinux kernel config):
http://pastebin.com/zxKUunY2
Pedro
Strange things happens with SQLite.
DeleteI tested with acpi+performance and the results with SQLite are 2 times worse than with acpi+ondemand, but 'John the Ripper' and pgbench are on par with CFS.
I've added the results here:
http://openbenchmarking.org/result/1612070-TA-CVSVSVRQ891
Pedro
@Pedro
DeleteThanks for this addtional test. It reminds me the "lost speed" issue in current VRQ, it is a known issue and current design itendtion, cpu will go to idle instead of look for tasks from other run queue when cpu is not running at top speed. This doesn't make sense but it is a workaround before I port that missing feature in previous vrq to 0.89.
I have observed "lost speed" more often these few days, maybe some code changes trigger the "lost speed" more oftern than used to be. That may explain benchmark regression in recent releases, while the performance governor benchmark are on par with CFS.
For the strange sqlite benchmark with performance governor, would you please try to get into performance governor in differnet ways and see how sqlite benchmark are? There is a commit to fix the issue for performance governor, but I am afraid that it is not working as expected in some senarios, resulting in the scheduler still think the cpu doesn't at top speed. I'll double check that commit tomorrow.
BR Alfred
@Alfred
DeleteThanks for the info.
I ran the sqlite benchmark again with performance governor and this time I got 28.50 Seconds, which is better than CFS and VRQ0.89f_Ondemand.
I also ran the same command as 'the phoronix-test-suite' through a script (cat sqlite-insertions.txt | sqlite3 benchmark.db), using both sqlite3 binaries from the phoronix-test-suite and from Archlinux repo.
I can't reproduce the bad results with performance governor anymore.
The results are the same with both binaries.
Performance governor is now faster than ondemand, which is expected.
Moreover, if I put the database in RAM, the benchmark is instantaneous (< 100ms). So I think sqlite benchmark is measuring 'scheduler+block device layer' performance, and that the 'block device layer' is the most important part (but I am a newbie here).
So, to sum up, I don't know what happened with the initial bad results with VRQ0.89+performance.
Pedro
@Pedro
DeleteThanks for the tests you have done. The initial bad results may cause by switching cpufreq driver from intel to apci performance governor, by chance, the scheduler may not sync with cpufreq changes. I have a patch for it, and will be include in 4.9 release. Hopefully can be done this week.
@Alfred,
ReplyDeleteI tried to post earlier but apparently my post was eaten :)
So, I tested 4.8.14 + 0.89f release and did not encounter strange frequency things, I suppose 4.8.12 was to blame, I posted results on my google sheet as well.
Br, Eduardo
@Eduardo
DeleteI have posted you earlier eaten reply above, :)
Next vrq release for 4.9 kernel will be in 1 or 2 days, a working vrq kernel is running here, I am checking if there any missing sync-up and double-check if some sync-up fix still be needed.
BR Alfred