tag:blogger.com,1999:blog-2963790426029213933.post8047285230409887569..comments2024-02-29T00:33:07.382-08:00Comments on Alfred Chen's Blog: VRQ 0.95b releaseAlfred Chenhttp://www.blogger.com/profile/03164306846702841944noreply@blogger.comBlogger47125tag:blogger.com,1999:blog-2963790426029213933.post-82188778016649979892017-06-03T11:02:30.251-07:002017-06-03T11:02:30.251-07:00@jwh7:
I'm sorry, this shouldn't sound tha...@jwh7:<br />I'm sorry, this shouldn't sound that impolite as it eventually could be understood. I just didn't get the link between the information I provided and the question/ suggestion you gave. So far, I haven't tested any of the debug modes but will have look at it over the weekend. Primarily I wanted to inform about a possible "workaround" and am wondering until now, why noone else experiences this (?).<br /><br />BR, Manuel KrauseAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-83436208188976889222017-06-02T20:10:37.734-07:002017-06-02T20:10:37.734-07:00@jwh7: Thanks for kidding.
BR, Manuel Krause@jwh7: Thanks for kidding.<br />BR, Manuel KrauseAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-44815949964846898232017-06-02T19:23:04.326-07:002017-06-02T19:23:04.326-07:00Have you tested any of the debug modes?
https://ww...Have you tested any of the debug modes?<br />https://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txtjwh7https://www.blogger.com/profile/09659185315567537391noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-62755551902087877562017-06-02T08:23:29.110-07:002017-06-02T08:23:29.110-07:00Does someone of you still suffer from the suspend/...Does someone of you still suffer from the suspend/resume issue that Alfred refers to in his top message?<br />By coincidence I've got a new finding: While trying to help with kernel bugzilla 188281, I had to swith to CONFIG_PM_DEBUG=y (but nothing in the submenu enabled). Unlike the naming including DEBUG, this setting really speeded up resume from hibernation and seems to also add reliability. I haven't experienced any slowdown or side-effect with it.<br /><br />BR, Manuel KrauseAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-41873571137514247072017-05-25T12:30:20.708-07:002017-05-25T12:30:20.708-07:00Another "Oh!": Some minutes after KDE wa...Another "Oh!": Some minutes after KDE was up after a third resume from S2DISK with the proposed additional patch, my 4.11.2 system locked up all of the sudden. So, it is not safe for now. Forget it and forgive me.<br /><br />BR, Manuel KrauseAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-9871737538333523952017-05-25T09:04:40.104-07:002017-05-25T09:04:40.104-07:00Oh, just after writing I realised, that 4.11.3 is ...Oh, just after writing I realised, that 4.11.3 is out. Let's see what it can fix hopefully.<br />BR, Manuel KrauseAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-89248612702145286222017-05-25T09:02:22.654-07:002017-05-25T09:02:22.654-07:00Mmmmh, so many commits in the queue for 4.11.3 but...Mmmmh, so many commits in the queue for 4.11.3 but still not released. And 4.10.17 is tagged as [EOL] so early. :-(<br />I still patch my 4.11.2 with the ones from above (https://cchalpha.blogspot.com/2017/05/vrq-095b-release.html?showComment=1493904291320#c4422413702620511499), but already had one failing S2RAM. Regarding S2DISK I'd also need to collect more cycles.<br /><br />While reading through the Hibernation/Suspend Bugzilla (https://bugzilla.kernel.org/buglist.cgi?bug_status=__open__&component=Hibernation%2FSuspend&order=changeddate%20DESC%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id&product=Power%20Management&query_format=advanced) I've found one patch snippet at the end of https://bugzilla.kernel.org/show_bug.cgi?id=188281 (only worth to read the latest comments at the bottom) that may be of benefit for some of you eventually: https://bugzilla.kernel.org/attachment.cgi?id=256709.<br />It's now in my early testing cycles and at least didn't harm S2RAM and S2DISK on my system so far.<br /><br />BR, Manuel KrauseAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-941665465639326212017-05-25T01:21:49.403-07:002017-05-25T01:21:49.403-07:00@Alfred
I'm looking forward to that feature. T...@Alfred<br />I'm looking forward to that feature. Thanks for the explanation.<br /><br />Regards,<br />DzonAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-88964137232771974072017-05-24T23:49:14.886-07:002017-05-24T23:49:14.886-07:00@Manuel
Good to know there is no regression. Less ...@Manuel<br />Good to know there is no regression. Less work to put into my todo lest, :)<br /><br />@Eduardo<br />For intel cpu, take a 2 core 4 threads cpu for example, when one one thread is active, it can boost to max cpu speed, saying 3.4. When only two threads in different cores are active, cpu can boost to 2.9(less than 3.4), when all 4 threads are active, it can only boost to 2.6. It's limited by the heat generated by cpu. I think this also apply to AMD's cpu.<br /><br />And by the way, for the case of 2 active thread above, if scheduler can kick off workload on two threads in different cores, both threads can boost to 2.9, totally we have 2*2.9=5.8. But if 2 threads are in the same core, each thread just have about 70%(?) effectiveness as they share resources among each other. Currently, VRQ doesn't aware of smt cores and look at them as physical cores, that's why VRQ doesn't play good in benchmark when under <100% number of cpu workload comparing to mainline scheduler. I am current working on feature to make VRQ aware of smt cores and kick off workload smartly. Hopefully it can be done before next kernel cycle.Alfred Chenhttps://www.blogger.com/profile/03164306846702841944noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-86384143166905826912017-05-24T23:20:16.885-07:002017-05-24T23:20:16.885-07:00@Eduardo
Thanks for the dmesg info. I haven't ...@Eduardo<br />Thanks for the dmesg info. I haven't studied Ryzen cpu topology closely. But from your dmesg, I can see a lovely 16 smt cores cpu, group by 2 cpu groups, each group has 4 cores and each core has two smt cores. :)Alfred Chenhttps://www.blogger.com/profile/03164306846702841944noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-29795248514462749072017-05-24T03:58:54.483-07:002017-05-24T03:58:54.483-07:00@Manuel,
Yeah, it's something like that, Brai...@Manuel,<br /><br />Yeah, it's something like that, BrainFlockScheduler sounds about right :)<br />Since 4.11 flocks up my intel, I'm back to 4.10.17 + VRQ + nohz_full. Let's see how that fares in long term.<br /><br />@Alfred,<br />I do You still use some sort of "sticky task" thing? See, I ask because, at least for Ryzen, I have 8 cores and max turbo is 3.7GHz w/ 1 or 2 cores active, all 8 active have max 3.2GHz, if, for instance, game or any single threaded app gets shuffled amongst all cores together with all those little and many processes, CPU doesn't really reach max turbo. Or I don't understand that shuffle and max turbo thing right :) Can You please comment on this matter, maybe sched some light? :)<br />Thanks.<br /><br />BR, EduardoAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-76631708581751323512017-05-23T08:10:43.233-07:002017-05-23T08:10:43.233-07:00@Eduardo:
First of all, thank you for the explanat...@Eduardo:<br />First of all, thank you for the explanation(s). So, hehe, VRQ is based on the BrainFlockedScheduler (TM) :-)))<br />And yes, your assumptions are all right (C2D, acpi_cpufreq and accessing actual speed). I hope to remember this stuff in future. But I really don't remember having suffered from such symptoms like yours on this machine since I use it for ~5y.<br /><br />BR, Manuel KrauseAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-29947660458881329732017-05-22T21:51:56.690-07:002017-05-22T21:51:56.690-07:00@Manuel,
since You have C2D (if I recall correctl...@Manuel,<br /><br />since You have C2D (if I recall correctly), You can use only acpi cpufreq governor and can not use i7z to determine actual cpu speed, so I guess You can use this: cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq<br />You can use stress -c 1 as well, to check whether it scales up at that moment.<br /><br />My system was affected for about 10 times in couple of years by this cpu frequency thing. Not too often, but when it happens, it's frustratingly slow, I have to reboot to have the speed back.<br /><br />"Flocking up" is saying the f-word w/o getting censored :)<br /><br />BR, EduardoAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-46110408218043180772017-05-22T13:45:54.795-07:002017-05-22T13:45:54.795-07:00@Eduardo:
Please, let me know what exact info you ...@Eduardo:<br />Please, let me know what exact info you like to see from my side (propose console commands). It seems that my system is too old or too "well configured" to be NOT affected. As you can read above, the slowness of my FF was a one-shot bad experience only.<br />BTW, what do you mean with "flocking up"? (words not familiar to me)<br /><br />BR, Manuel KrauseAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-14450245991496137632017-05-22T11:59:07.127-07:002017-05-22T11:59:07.127-07:00@Manuel or anyone else,
since You talk about rath...@Manuel or anyone else,<br /><br />since You talk about rather nasty sudden slowdowns, I'll add my as well, in previous blog post (0.95 for 4.10, http://cchalpha.blogspot.com/2017/04/vrq-095-release.html?showComment=1494834080289#c1158054218901428452 ) and even before, I have added a comment about my strange sudden situation with cpu frequency, do anyone ever experienced that? It happens when resuming from S3 I guess, as I put laptop to sleep rather than hibernate.<br />That, as far I have observed, happens only on Dell Skylake laptop, more times than I wish :) All of a sudden it does not scale until reboot which leads to sudden slowdown. Manuel's finding about slowness for FF sorta kinda sounded like it.<br />Manuel, did You check frequency scaling, actual freq and stuff like that when it happened?<br /><br />P.S. 4.11 itself (vanilla, MUQSS, VRQ) "flocks up" my integrated intel card monitor resolution switch functionality (really annoying), so I can't use it on laptop, my experience w/ 4.11 will be only on Ryzen I suppose.<br /><br />BR, EduardoAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-24182365289173328062017-05-22T08:43:32.082-07:002017-05-22T08:43:32.082-07:00@Alfred:
I have to apologise. Today I've found...@Alfred:<br />I have to apologise. Today I've found time to do more correct tests under most comparable conditions: 90 same tabs loading until finished, both kernels VRQ, all tests within last 30 minutes, but run sequentially with reboots between them.<br />4.10.16 w/o. idle load: 4m23s<br />4.10.16 with idle load: 4m24s<br />4.11.2 w/o. idle load: 4m22s<br />4.11.2 with idle load: 4m13s<br /><br />So, most likely my last impression went wrong or I've had added/ now removed one tab with extremely slow server response that led to my writing. Anyways this test is obviously unpredictable -- but luckily shows here now: last kernel + VRQ plays as fine as the current ones in this test case.<br /><br />BR, Manuel KrauseAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-22302153380761810452017-05-21T10:12:19.734-07:002017-05-21T10:12:19.734-07:00@Alfred,
here it is.
br, Eduardo
[ 2.481574]...@Alfred,<br /><br />here it is.<br /><br />br, Eduardo<br /><br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[0] smt 0x00000002<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[0] coregroup 0x000000fc<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[0] core 0x0000ff00<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[1] smt 0x00000001<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[1] coregroup 0x000000fc<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[1] core 0x0000ff00<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[2] smt 0x00000008<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[2] coregroup 0x000000f3<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[2] core 0x0000ff00<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[3] smt 0x00000004<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[3] coregroup 0x000000f3<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[3] core 0x0000ff00<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[4] smt 0x00000020<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[4] coregroup 0x000000cf<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[4] core 0x0000ff00<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[5] smt 0x00000010<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[5] coregroup 0x000000cf<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[5] core 0x0000ff00<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[6] smt 0x00000080<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[6] coregroup 0x0000003f<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[6] core 0x0000ff00<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[7] smt 0x00000040<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[7] coregroup 0x0000003f<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[7] core 0x0000ff00<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[8] smt 0x00000200<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[8] coregroup 0x0000fc00<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[8] core 0x000000ff<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[9] smt 0x00000100<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[9] coregroup 0x0000fc00<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[9] core 0x000000ff<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[10] smt 0x00000800<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[10] coregroup 0x0000f300<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[10] core 0x000000ff<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[11] smt 0x00000400<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[11] coregroup 0x0000f300<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[11] core 0x000000ff<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[12] smt 0x00002000<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[12] coregroup 0x0000cf00<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[12] core 0x000000ff<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[13] smt 0x00001000<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[13] coregroup 0x0000cf00<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[13] core 0x000000ff<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[14] smt 0x00008000<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[14] coregroup 0x00003f00<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[14] core 0x000000ff<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[15] smt 0x00004000<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[15] coregroup 0x00003f00<br />[ 2.481574] vrq: sched_cpu_affinity_chk_masks[15] core 0x000000ff<br />[ 7.323182] BFS enhancement patchset VRQ 0.95b by Alfred Chen.<br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-40995666896607881962017-05-21T09:02:28.961-07:002017-05-21T09:02:28.961-07:00@Euardo and whom owns Ryzen cpu
Would you please p...@Euardo and whom owns Ryzen cpu<br />Would you please post a "dmesg | grep -i vrq" output of the system, so I can catch the topology setup on Ryzen cpu? Many thanks.Alfred Chenhttps://www.blogger.com/profile/03164306846702841944noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-4845581897143637122017-05-21T09:00:23.434-07:002017-05-21T09:00:23.434-07:00@Manuel
As you can tell, there is no new feature o...@Manuel<br />As you can tell, there is no new feature on VRQ0.95b compared to VRQ0.95 on 4.10, just the sync up codes.<br />So it just happened when firefox loading tabs?Alfred Chenhttps://www.blogger.com/profile/03164306846702841944noreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-72825508021281177092017-05-20T15:11:16.157-07:002017-05-20T15:11:16.157-07:00@Alfred:
I've now switched to your VRQ 0.95b w...@Alfred:<br />I've now switched to your VRQ 0.95b with kernel 4.11.2. It's ugly somehow:<br />Having an idle load like my two WCG clients and then starting a tab-blown-up firefox, the firefox' loading can take ages compared to 4.10. It seems heavily braked out by your algorithms.<br /><br />BR, Manuel KrauseAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-31239857147449262452017-05-16T09:12:27.190-07:002017-05-16T09:12:27.190-07:00regarding my [off-topic] from just above:
Just wan...regarding my [off-topic] from just above:<br />Just want to inform you about my new findings. It was no FS or disk corruption at all. Today my system recovered 1,1GB from my root FS (correct ext4 since some days) by some magic coincidence, so that I was able to check the differences to a safety backup taken one week ago. And -- shame on me :-( -- it was only a _succeeded_ crash dump of kwin_X11 in folder /var/lib/systemd/coredump. Earlier, no crashdump succeeded due to low disk space (and I wasn't aware of that location). I had taken counter measures against coredumps before, but obviously haven't all possible of them in use against it on openSUSE 42.2/ systemd 228.<br /><br />My testing of in-kernel suspend-to-disk, still with 4.10 kernel, now at 4.10.16, still didn't get above 5 followups. No. 6 failed again (second row of realistic use test). Remarkable with this kernel: I don't get random segfaults any more.<br />If someone of you has results of in-kernel suspend-to-disk with VRQ (with or without the two i915 related patches above), please let us know. BTW, the MuQSS community hasn't reported issues with it and 4.11 kernel up to now.<br /><br />BR, Manuel KrauseAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-83793823855022902732017-05-13T07:11:49.661-07:002017-05-13T07:11:49.661-07:00@Alfred,
tested using IDLE policy, that worked fi...@Alfred,<br /><br />tested using IDLE policy, that worked fine. Rising up load to 10K worked fine as well.<br /><br />BR, EduardoAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-53836726429965894402017-05-11T09:34:04.368-07:002017-05-11T09:34:04.368-07:00[off-topic]
This time my porting job of TOI went w...[off-topic]<br />This time my porting job of TOI went wrong utterly. First step of only fixing wrongly-patching hunks didn't make it resume. Second step of adding Nigel's most recent own commits (upon his newer TOI codebase) made it resume, but resulted in an ugly corruption of my root fs. After resuming well the system bloated the ext4 root partition up to the max. This was two days ago and I still have no clue, where the "bloating" landed. Forced e2fsck and a forth-and-back copy held this fs for o.k. :-(<br />Strange side-note: Apparently this root fs firms as without journal, although not having changed it, only having upgraded the software through the openSUSE distros.<br /><br />Yes, yes, with some more knowledge this TOI-mess wouldn't have happened.<br /><br />BR, Manuel KrauseAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-32479049099975993952017-05-08T10:19:08.153-07:002017-05-08T10:19:08.153-07:00ATM I'm so upset, that I'm working on refu...ATM I'm so upset, that I'm working on refurbishing my humble old TuxOnIce port from 4.33/for 4.9 according to 4.10 now.<br />In-kernel suspend-to-disk sucks so much. Regarding speed and reliability at least.<br /><br />BR, Manuel KrauseAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2963790426029213933.post-46160686943641196892017-05-08T06:50:46.822-07:002017-05-08T06:50:46.822-07:00It's a pity. My sixth suspend-to-disk attempt ...It's a pity. My sixth suspend-to-disk attempt locked up my system just after initiating it via KDE. Never had that before, earlier it only failed upon resume, as I wrote before. <br />There was no extreme memory or cpu or i/o or swap load at that moment. Seems like there are more things to fix in suspend-to-disk. :-( This is still with 4.10.14. If one of you people has a hint -- thank you for it! I've already read some of the actual bugzilla threads in Power Management/ Hibernation/Suspend but am not through all of them yet.<br /><br />At least the two patches don't make things worse, they deliver it to a new stage ;-)<br /><br />BR, Manuel KrauseAnonymousnoreply@blogger.com