Here comes the all in one vrq patch v4.5_0469_vrq0 which now is based on the latest BFS 0469, of course the new sched_interactive design in the latest BFS has been removed and be replaced by the task policy based caching timeout design in VRQ.
Basically, this release doesn't introduce much code changes comparing to the previous release, just put the code based on the latest BFS for better maintenance in the future.
As usual, I'm still waiting the upstream BFQ patch for 4.5 to update the GIT repositories. If you have any question/feedback about the VRQ patch, please let me know.
Have fun with this new release!
I have pushed the latest vrq0 code to my repository on bitbucket and github. Individual commit can be viewed now.
Maybe it's just too early... but I cannot download this patch (although it appears in the repository).ReplyDelete
BR Manuel Krause
Bad news. I can't download it neither. I have open a ticket to bitbucket, hopefully they have it fixed soon.Delete
It works now, I have done nothing about it. Patch file can be download and no damage in it as I have checked. So, please go ahead, :)Delete
A little off-topic on here, but...
Have you had luck to boot a kernel with your current pf-4.5 TuxOnIce implementation?
I've fetched the patch from your repo, when 4.5.0 was relatively fresh, but get a BUG at bootup with something like schedule while atomic. The call trace mentions schedule, schedule_bug, set_cpus_allowed_ptr and several toi_ functions before my disks get fully initialized.
I hope, you can help a little,
BR Manuel Krause
Btw, @Alfred, could you please also take some look at that bugreport? I've tried to dig into locking code, but besides one extra spinlock found nothing new in TOI code diff. Still have to wait for Nigel's response :(.Delete
@post-factum: Thank you very much for letting me/ us know about your reports. I do get the same errors.Delete
I really hope for a fix (Nigel?!), as the 4.5 kernel is the second major kernel in a row that I cannot test. In 4.5 at least my gfx issues vanished.
BR, Manuel Krause
I believe I've found the root of the issue, but as of now have no idea how to fix it.Delete
The description is under TOI ticket here: https://github.com/NigelCunningham/tuxonice-kernel/issues/13#issuecomment-210982607
Thank you for investigating this so deeply. And finally Nigel wrote a first reply ^^Delete
For now I've reverted the one commit in question -- and everything, including VRQ0, BFQ and TuxOnIce hibernation, seem to work reliably!
Although I now get another call trace: http://paste.opensuse.org/44184299
Thanks for two of you to investigate the issue. Haven't checked email during last weekend.Delete
I'd like to ask if the original BFQ 4.4.0-v7r11 works for kernel 4.5 or any other changes needed to make it works on 4.5. I ask this b/c I got about 3 seconds 50% workload kernel compile improvement in 4.5 comparing to 4.4, that's a huge improvement. Consider there is no huge code changes in scheduler code, and the only still missing patch is BFQ on my 4.5, I'd like to add BFQ in and rerun the tests.
Forward-ported BFQ runs well for me. In fact, this is what Paolo suggested for those who want BFQ for 4.5 before official release. So just merge and give it a try.Delete
I have seen your v4.5-pf1 released. Any feedback to the scheduler part? I'd like to add some new changes and release vrq1 soon.
Nigel's patch for 4.6.0-rc4 mainly only reflects our discussions' result. It's different and working, but not with my loop mounted file. It would have been too nice, wouldn't it?
BR and thank you for your work and invested time!
I guess the patch for 4.6-rc4 is broken as well because I see lock release, but not taking the lock... No idea, why that happens with TOI at all.Delete
Should the vanilla hibernation work for you?
I've noticed this, too. I've got too little knowledge to comment on it.Delete
The vanilla hibernation doesn't show any issue. Except for firefox getting usable again is terribly slow :-( but that's typical when not using TOI.
BR Manuel Krause
I've now done the "dumb" job to forward-port my last known working TOI patch (for kernel 4.3.3) to apply and cleanly compile on kernel 4.5.2. I didn't bother with cosmetic changes or line offsets.
No related compile warnings -- and now I can have a loop mounted ext4 file staying alive again, relevant for anyone who uses truecrypt or sth. like that.
One thing remains: I get almost the same WARNING like in http://paste.opensuse.org/44184299 on the first hibernation.
I've uploaded the "ported" patch to http://workupload.com/file/TFFm8Ka
so someone with knowledge can review and judge the changes, that make current TOI failing.
BR Manuel Krause
@Alfred, no issues reported against scheduler AFAIK. All my 3 nodes work OK as well.ReplyDelete
No doubt, I'm ready to merge and test vrq1 as well.
My machine is also running fine, regarding the scheduler, with almost the same patches' setup that post-factum uses. I, in fact, only leave the UKSM out.
The only problems arise from the missing love and care for the TuxOnIce patch during the last months.
With the omitted TOI commit (mentioned above, && see post-factum's repo) -- what I need to omit to boot the 4.5 kernel at all -- I get a failing hibernation, whenever a file is loop-mounted on top of a partition. In my first case it was a truecrypt file on top of an ext4 partition, but I also verified that it happens with pure ext4 files loop-mounted on ext4 partitions as well.
Btw., I'm also looking forward to your ongoing "future" work on VRQ!
BR Manuel Krause
It's not huge/new feature for VRQ, just a continuous improvement for the "sticky task". In short, I'm trying *not* putting sticky task into grq, to avoid grq locking conflict. The test result looks pretty good for 2 of my pc/laptop, and I will release a -test branch for testing once it's tested on my old notebook tonight.
The new code just *not* booting my old notebook, I have found the cause and trying to solve it in a proper way. I have to forecast the test branch release at this weekend.
This comment has been removed by the author.ReplyDelete
Alfred, one of my users reported this panic while suspending his machine with vrq:ReplyDelete
Reverting vrq fixes the issue for him. Ideas?
From the call trace, it looks not related to scheduler code and panic at putty low level spinlock functionality.
BFS/VRQ does modified the cpu hot-plug code as register callback when suspend/resume but it works well. Anyway I'd double check those logic as well.
Does the user use 4.4 pf kernel as well and has same issue with 4.4 kernel?
It was reported that the issue occurs even without VRQ. So, nvm.Delete