tag:blogger.com,1999:blog-2963790426029213933.post2979940113572575264..comments2024-02-29T00:33:07.382-08:00Comments on Alfred Chen's Blog: VRQ 0.93a releaseAlfred Chenhttp://www.blogger.com/profile/03164306846702841944noreply@blogger.comBlogger22125tag:blogger.com,1999:blog-2963790426029213933.post-65353460962525797702017-03-16T09:45:04.183-07:002017-03-16T09:45:04.183-07:00@Alfred:
Any news from your VRQ programmer's f...@Alfred:<br />Any news from your VRQ programmer's front?! :-) <br /><br />Don't misunderstand me, I have absolutely no reason for any complaint. Atm. everything works fine and smooth with kernel 4.10.3 + VRQ 0.93a and BFQ v8r8+fix. <br />The complete migration to openSUSE 42.2 needed much more cleanup than expected.<br />Also I've taken back WBT inclusion completely from .config, as I only use BFQ as disk scheduler, and benefits in combination are not proved. I've also reverted one runtime setting, what seemed to help with my previous precarious memory setup, /proc/sys/vm/vfs_cache_pressure == 300, back to system default of 100. This and also the recent kernel patches appear to improve resume-from-hibernation speed significantly (meaning a tabs-bloated Firefox getting responsive asap like with former TuxOnIce).<br /><br />BR, Manuel KrauseAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-85869761196143895312017-03-12T11:36:50.704-07:002017-03-12T11:36:50.704-07:00Hi Alfred,
thanks for the tip,
yes - it not only...Hi Alfred,<br /><br />thanks for the tip,<br /><br />yes - it not only is impaired, in fact the whole system sort of locked up in one instance, the other instance it kept on playing sound as if nothing happened but did NOT react to input anymore (also screen output was frozen) ;)<br /><br />Still searching how to apply SCHED_IDLE to gentoo, I'm sure I'll find it soon-ish<br /><br />kernelOfTruthnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-62337187916489491192017-03-07T22:26:27.523-08:002017-03-07T22:26:27.523-08:00@all
Here are my CFS vs VRQ test results I want to...@all<br />Here are my CFS vs VRQ test results I want to share<br />On non-SMT machine, no regression is found, from 50% to 300% workload.<br />On SMT machine, regression are found from 50% to 300% workload in both 4.9 and 4.10 kernel.<br />The regression in >= 100% workload is out of my expectation. So I have to trace it far back to 4.8 kernel, will keep you updated when have more findings.Alfred Chenhttps://www.blogger.com/profile/03164306846702841944noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-29521259443854342252017-03-02T02:30:55.513-08:002017-03-02T02:30:55.513-08:00@Alfred
SCHED_MC_PRIO is enabled, but the doc says...@Alfred<br />SCHED_MC_PRIO is enabled, but the doc says it has no effect on CPU without Intel Turbo Boost Max Technology 3.0, and my Intel 4770k doesn't have it.<br /><br />PedroAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-43170584204342273332017-03-01T16:35:27.826-08:002017-03-01T16:35:27.826-08:00@Pedro
BTW, have you enabled SCHED_MC_PRIO for v4....@Pedro<br />BTW, have you enabled SCHED_MC_PRIO for v4.10 for your tests? I am testing with this new kernel option in CFS and trying to get more test result from others.Alfred Chenhttps://www.blogger.com/profile/03164306846702841944noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-58891968222559046382017-02-28T09:43:43.770-08:002017-02-28T09:43:43.770-08:00@Alfred:
Thank you for the info, also for the earl...@Alfred:<br />Thank you for the info, also for the earlier one posted above. Good luck with developing. We all appreciate and enjoy your good work's progress!<br /><br />BR, Manuel KrauseAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-3923206240581077372017-02-28T08:39:37.310-08:002017-02-28T08:39:37.310-08:00@Pedro
Thanks for the benchmarks. I have finished ...@Pedro<br />Thanks for the benchmarks. I have finished my sanity tests vs CFS on non-SMT machine, and the result shows that there is no regression. And the test is still running at a SMT notebook, will let you know the result once it is done.<br />But most likely(and my best guess), VRQ select smt cpu while other phy-core is availiable.<br /><br />Once it is comfirmed, I will start work out a sulotion for it.Alfred Chenhttps://www.blogger.com/profile/03164306846702841944noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-71350990604556494652017-02-28T04:08:25.893-08:002017-02-28T04:08:25.893-08:00Hi Alfred and thank you for your work.
Here are t...Hi Alfred and thank you for your work.<br /><br />Here are the usual throughput benchmarks on 4.10:<br />https://docs.google.com/spreadsheets/d/163U3H-gnVeGopMrHiJLeEY1b7XlvND2yoceKbOvQRm4/edit?usp=sharing<br /><br />This time I also tried VRQ with the recommended 1000Hz.<br />I've added the test of 4 lame in parallel, because it also shows the throughput regression under half load.<br />I've noticed that when I set the 4 lame process affinity to different cores with taskset, there is no regression, but I guess that's expected.<br /><br />PedroAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-21953577122329905292017-02-27T16:30:47.677-08:002017-02-27T16:30:47.677-08:00@Manuel
Things on my VRQ list are
1. <100% work...@Manuel<br />Things on my VRQ list are<br />1. <100% workload tests vs CFS on diff machines(smt and non-smt)<br />2. Remove rd and sd in VRQ(2k+ LOC)Alfred Chenhttps://www.blogger.com/profile/03164306846702841944noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-57577053072734015952017-02-27T11:04:12.950-08:002017-02-27T11:04:12.950-08:00Btw., besides of using BFQ-v8r8 and enabling (now ...Btw., besides of using BFQ-v8r8 and enabling (now in-kernel) WBT I've also applied Con's "Swap-sucks" patch (http://ck.kolivas.org/patches/4.0/4.10/4.10-ck1/patches/0022-Swap-sucks.patch). With my former RAM a no-go, now it's working fine.<br />BR, Manuel KrauseAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-46039767038944330502017-02-27T10:45:12.514-08:002017-02-27T10:45:12.514-08:00@Alfred:
Yes, man. I'm really glad that things...@Alfred:<br />Yes, man. I'm really glad that things settled so well functioning. Regarding your hard work on VRQ (and also my successful upgrade marathon with Susy). ;-)<br /><br />Any news on what's in your pipeline for VRQ?<br /><br />Thank you and BR, <br />Manuel KrauseAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-67586727787296481252017-02-27T07:43:00.196-08:002017-02-27T07:43:00.196-08:00Ah, ya I disabled CPUFREQ in my latest config, sin...Ah, ya I disabled CPUFREQ in my latest config, since the netbook can't use it. And yes; vrq compiles now for it. I picked up 075f828 and 6af80e6. Thanks @Alfred.jwh7https://www.blogger.com/profile/09659185315567537391noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-50535003189965620312017-02-26T17:10:06.567-08:002017-02-26T17:10:06.567-08:00@Manuel
Good to know it works for you. On my site,...@Manuel<br />Good to know it works for you. On my site, suspend in VRQ kernel is very reliable for me for 2 or 3 kernel releases.Alfred Chenhttps://www.blogger.com/profile/03164306846702841944noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-39719910581473023572017-02-26T16:57:16.578-08:002017-02-26T16:57:16.578-08:00@jwh7
Thanks for reporting this compilation issue....@jwh7<br />Thanks for reporting this compilation issue. It's not related to UP, but disabled CPU_FREQ. It's an issue in VRQ. I have pushed a fix to git. Please have a check and any other issues, please let me know.<br /><br />https://bitbucket.org/alfredchen/linux-gc/commits/6af80e60987f86c4ce41fd02e333a34d4cdb03c8Alfred Chenhttps://www.blogger.com/profile/03164306846702841944noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-89331328954403135632017-02-26T16:39:27.336-08:002017-02-26T16:39:27.336-08:00@KernelOfTruth
In your usage, I'd suggest use ...@KernelOfTruth<br />In your usage, I'd suggest use IDLE policy for compilation rather than use ISO policy for mpv playing. The ISO policy task has higher priority than even kernel threads, if ISO occupied too much cpu power, the whole system interactivity would be impacted.Alfred Chenhttps://www.blogger.com/profile/03164306846702841944noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-21888755665812312562017-02-26T16:11:21.991-08:002017-02-26T16:11:21.991-08:00@Alfred, thanks again...x64 compiled fine, but 32-...@Alfred, thanks again...x64 compiled fine, but 32-bit UP fails with:<br />kernel/sched/bfs.c: In function ‘update_rq_clock_task’:<br />kernel/sched/bfs.c:2367:18: error: implicit declaration of function ‘irq_time_read’ [-Werror=implicit-function-declaration]<br />s64 irq_delta = irq_time_read(cpu_of(rq)) - rq->prev_irq_time;jwh7https://www.blogger.com/profile/09659185315567537391noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-75104343017042887732017-02-26T16:09:26.526-08:002017-02-26T16:09:26.526-08:00This comment has been removed by the author.jwh7https://www.blogger.com/profile/09659185315567537391noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-81840706703935429302017-02-26T12:32:36.226-08:002017-02-26T12:32:36.226-08:00Most probably the former limited RAM situation led...Most probably the former limited RAM situation led to the issues I've had faced. As this notebook uses shared RAM for gfx, I assume that amounts of this gfx mem also went into swap. Would be evidenced by the fact that before my RAM upgrade every swappiness < 40 led to system starvation over time.<br />I cannot estimate how much influence the omitting of dead TuxOnIce code has, but if in-kernel-hibernating keeps it's reliability now, I won't look back. (Before RAM upgrade Firefox needed a very long time to get interactive with in-kernel-hibernation.)<br /><br />BR, Manuel KrauseAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-18757153955593551032017-02-25T17:09:38.351-08:002017-02-25T17:09:38.351-08:00Compilation in portage was NOT reniced,
so it sho...Compilation in portage was NOT reniced,<br /><br />so it should naturally cause interruptions (seems the rt-kernel is less susceptible in that regard)<br /><br />kernelOfTruthnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-23346440443697886362017-02-24T14:16:53.294-08:002017-02-24T14:16:53.294-08:00@Alfred:
Thanks for the new release. It's runn...@Alfred:<br />Thanks for the new release. It's running fine now for some hours with BFQv8r8, 512Hz and your older tune-ups. <br />After recently upgrading my RAM from 4 to 8 GB and my openSUSE from 13.1 to 42.2, my humble tuxonice port got less reliable with 4.9.xy (50% hibernation successes, but RAM upgrade is out of doubt and does more good), I've left TOI out for this kernel... and surprise... in-kernel hibernation works as fast as former TOI now. Atm. I can't explain it to myself. <br /><br />BR, Manuel KrauseAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-83586427114407846512017-02-24T13:41:05.699-08:002017-02-24T13:41:05.699-08:00Hi Alfred,
thanks for the quick port and fixes f...Hi Alfred,<br /><br /><br />thanks for the quick port and fixes for 4.10 !<br /><br />I'm switching from a rt-kernel (4.8 + 4.9) [4.10-rt isn't available yet, and there are issues with using virtualbox with an rt-kernel (kernel not booting, etc.)],<br /><br />and latency in cyclictest is pretty low.<br /><br />While e.g. compiling vlc and watching a high-bitrate 1080p video in mpv (via baka-player),<br /><br />the behavior is about 30-50+% comparable to rt-kernel - there were a few short interruptions but almost immediately continued (performance demand shouldn't be very high by default mpv player, not sure if baka-player uses mpv.conf for playback).<br /><br />With an rt-kernel you can cause rather high load (e.g. compiling and updating stuff) and the multi-threaded mpv videos + vapoursynth still work in lots of cases,<br /><br />will see how VRQ behaves in that regard ...<br /><br />So far no issues discovered,<br /><br />videos with motion interpolation, upscaling, 48 fps, superxbr, debanding [using vapoursynth] appears working optimally when passing schedtool -I -e <br /><br />to mpv while the system is idle - no priority inversion so that the video would stutter.<br /><br />I'll report when I have gathered some more feedback,<br /><br />so far - so good :)kernelOfTruthnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-8439639829734128532017-02-24T11:48:12.129-08:002017-02-24T11:48:12.129-08:00Hi,
running here nicely on skylake and phenom II ...Hi,<br /><br />running here nicely on skylake and phenom II for some 10 hrs, it seems that CPU accounting is fixed here and the rest are ok.<br /><br />thanks,<br />EduardoAnonymousnoreply@blogger.com