tag:blogger.com,1999:blog-6469704299235308349.post8336361824290799030..comments2024-02-09T16:24:46.087+11:00Comments on -ck hacking: bfs 0.423, 3.4-ck2ckhttp://www.blogger.com/profile/02904761195451530213noreply@blogger.comBlogger48125tag:blogger.com,1999:blog-6469704299235308349.post-23814756699176733482012-10-05T06:38:43.264+10:002012-10-05T06:38:43.264+10:00nice Toolnice <a href="http://the-hacking-arena.blogspot.com" rel="nofollow">Tool</a>Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-61900713357373437292012-06-30T23:08:03.279+10:002012-06-30T23:08:03.279+10:00Hi Con,
thanks for your work. You are right. I re...Hi Con,<br /><br />thanks for your work. You are right. I recently tested the Vanilla 3.3.8 with the old -ck1 patchset with the old BFS and my mentioned problems with the badblock test during mkfs are completly gone.<br /><br />So its really the new BFS code.<br /><br />Thanks so far.<br />Regards MikeMikehttps://www.blogger.com/profile/12391045215046883684noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-67921667161474157582012-06-30T15:53:02.245+10:002012-06-30T15:53:02.245+10:00This comment has been removed by the author.Micronhttps://www.blogger.com/profile/00612104081287508741noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-29227822766876472502012-06-30T15:51:36.838+10:002012-06-30T15:51:36.838+10:00This comment has been removed by the author.Micronhttps://www.blogger.com/profile/00612104081287508741noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-63758467377108521842012-06-30T09:36:40.533+10:002012-06-30T09:36:40.533+10:00Ok looking at the pattern of lockups people are ha...Ok looking at the pattern of lockups people are having, I'm reasonably sure it's the block plugging code which I changed going into this BFS release. I will put together an update soon that backs out those changes to the old proven mechanism. Thanks everyone for your bug reports.ckhttps://www.blogger.com/profile/02904761195451530213noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-808744031021441202012-06-30T02:41:51.083+10:002012-06-30T02:41:51.083+10:00Just adding to my reports.
I abandonned the 3.4.3 ...Just adding to my reports.<br />I abandonned the 3.4.3 CFS + JUMP_LABEL test after 3d0h10m. Rock stable but really predictably unresponsive.<br />The 3.4.4 with BFS(only) +JUMP_LABEL crashed after ~8h.<br />Two days ago I had a complete lockup with that kernel+config but WITHOUT JUMP_LABEL after some hours. So it really has nothing to do with that config setting.<br />I've tried RIFS but that doesn't work on non-SMP systems at all.<br /><br />I feel a bit unsafe at the moment, when using BFS-patched kernels.<br /><br />ManuelAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-47216683930476867952012-06-30T00:49:00.906+10:002012-06-30T00:49:00.906+10:00Hi Con,
some more tests:
1. Hard Freeze with BFS...Hi Con,<br /><br />some more tests:<br /><br />1. Hard Freeze with BFS and USB(2) Stick badblock test (command: "mkfs.ext2 -L "Stickname" -m 0 -c -v /dev/sdb1"). Freeze after approx. 5 Minutes and 30%. (remark: with esata drives the freezes comes within 2 minutes)<br /><br />2. Starting in Runlevel 3 does not make a difference, freeze too with badblock test command (and nothing other tasks running)<br /><br />Btw. running the command with CFS and the new RIFS from Chen do not have this problem.<br /><br />Con, if you need additional infos or requests for this bug, I could try to help you.<br /><br />Thanks and regards<br />MikeMikehttps://www.blogger.com/profile/12391045215046883684noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-40716605693948993132012-06-27T02:19:39.415+10:002012-06-27T02:19:39.415+10:00Hi Manuel,
short answer: Only the Vanilla Kernel ...Hi Manuel,<br /><br />short answer: Only the Vanilla Kernel with CK2 patchset and CONFIG_JUMP_LABEL disabled.<br /><br />Regards MikeMikehttps://www.blogger.com/profile/12391045215046883684noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-474684053146498902012-06-26T04:50:30.542+10:002012-06-26T04:50:30.542+10:00Short Q: Which of your combinations did you test C...Short Q: Which of your combinations did you test CONFIG_JUMP_LABEL disabled? <br />Regards, ManuelAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-80947813575706189602012-06-26T04:21:31.646+10:002012-06-26T04:21:31.646+10:00Hi Con, I have Hard freezes with BFS,
I use zen k...Hi Con, I have Hard freezes with BFS,<br /><br />I use zen kernel (with BFS and BFQ, linux 3.4.4). Command "mkfs.ext4 -L Diskname -c -v /dev/sdb1" (SATA drive on esata connector) leeds to an hard freeze within minutes during bad block test. Not even the Magic SysRq keys do work anymore.<br />So I compiled zen with CFS, no problem, no freeze.<br />Zen with BFS but without BFQ -> freeze.<br /><br />So I tested it with Vanilla Kernel 3.4.4 and CK2 Patches -> freeze too.<br />Vanilla Kernel 3.4.4 with your patches but without BFS -> no freeze!<br /><br />PS: I even tested to disable in the discussion mentioned CONFIG_JUMP_LABEL and BFS, but freeze too.<br /><br />I use OpenSuse 12.1 and with the original Tumbleweed kernel 3.4.3 there is no such a problem.<br /><br />Regards MikeMikehttps://www.blogger.com/profile/12391045215046883684noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-31535350178894040762012-06-26T00:11:43.023+10:002012-06-26T00:11:43.023+10:00Yes, yes. I'm still waiting for 3.4.3 + standa...Yes, yes. I'm still waiting for 3.4.3 + standard scheduler with CONFIG_JUMP_LABEL = y to fail. But even with 65h of uptime it keeps running without issues (but, of course, with a worse interactivity than BFS). Side note: The CFS kernel does slow down after a certain time running, too.<br /><br />Don't know what to do now. Meanwhile I compiled a 3.4.4 + BFS + CONFIG_JUMP_LABEL, ready for next reboot.<br /><br />ManuelAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-76732063856000260322012-06-25T15:07:53.318+10:002012-06-25T15:07:53.318+10:00So what about your last test with CONFIG_JUMP_LABE...So what about your last test with CONFIG_JUMP_LABEL, Manuel? Results?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-41579362980504923822012-06-23T23:13:21.197+10:002012-06-23T23:13:21.197+10:00Just short to correct the above:
With BFS and CONF...Just short to correct the above:<br />With BFS and CONFIG_JUMP_LABEL = y my system halts after 23-32h.<br />With BFS and CONFIG_JUMP_LABEL = n my system keeps running after 49h.<br /><br />Now running standard scheduler with this CONFIG_JUMP_LABEL = y. 16h so far. I hope it breaks soon, I don't like it's experience.<br /><br />And: I don't claim that it has anything to do with BFS, I only asked if it could possibly be so.<br /><br />ManuelAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-42072675640297462072012-06-23T11:00:04.938+10:002012-06-23T11:00:04.938+10:00Con, our issue is not performance here:
Without JU...Con, our issue is not performance here:<br />Without JUMP_LABEL<br />1. Manuels system halts after a day<br />2. me (shutting down ervery night)<br />ps -e -o pcpu,bsdtime,stat,comm --sort -pcpu<br />gives me a rcuc/0 thread with 175 Million seconds run time<br />in rare cases (after hours).Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-66311606954108136182012-06-23T09:58:55.583+10:002012-06-23T09:58:55.583+10:00The "slow down" it mentions is when the ...The "slow down" it mentions is when the branch is the opposite of what is predicted. The idea is that there is a branch point where we know that 99% of the time we do code A and 1% of the time we do code B. Normally it would cost a little overhead to do code A and a little more overhead to do code B. With this optimisation feature enabled, it costs NO overhead to do code A and MORE overhead than before to do code B.<br /><br />This has nothing to do with BFS.ckhttps://www.blogger.com/profile/02904761195451530213noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-91702285399232946722012-06-23T09:51:52.338+10:002012-06-23T09:51:52.338+10:00Manuel, this Option normally brings a performance ...Manuel, this Option normally brings a performance boost. This is why I disabled it at first to have a more stable experience. But the last sentence in the help of the option: in rare cases there is a slow down to update conditions. <br /><br />This must have a side effect for BFS: I have no issues with BFS since I enabled this Jump_Label optimization.<br />Ciao from happy soccer Germany, RalphAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-73488650948035389362012-06-23T04:15:41.726+10:002012-06-23T04:15:41.726+10:00And the other way round?: May _this option_ affect...And the other way round?: May _this option_ affect the way BFS works?<br /><br />IIRC, it made BFS snappier on my old hardware. But that's subjective. Perhaps Ralph would share his experience with us.<br /><br />Thank you for your replies!<br />ManuelAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-42118036649817447562012-06-23T01:21:59.291+10:002012-06-23T01:21:59.291+10:00Con, wasn't it you, who looked into Solaris co...Con, wasn't it you, who looked into Solaris code just to recognize it as a saner framework? Which could easily come to the conclusion Linux source is more vulnerable to side effects... RalphAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-10887858280902964362012-06-23T01:08:06.111+10:002012-06-23T01:08:06.111+10:00Yes, that is what I wanted to answer to Manuel. An...Yes, that is what I wanted to answer to Manuel. And I looked it up, when I saw that I myself had this disabled. And I have this rcuc Kernelthreads systime shows going crazy. I just compile my kernel with enabled CONFIG_JUMP_LABEL. Perhaps this gives more time for BFS to behave normal. As the last sentence in the help of the option says:<br />"update of the condition is slower"<br />Ralph UlrichAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-50892523899060306982012-06-23T00:24:35.902+10:002012-06-23T00:24:35.902+10:00This is a low level change to how inbuilt expect f...This is a low level change to how inbuilt expect functions are compiled by gcc into assembly utilising an x86 feature. Can't see how this is affected by BFS directly or indirectly.ckhttps://www.blogger.com/profile/02904761195451530213noreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-66295758370792078082012-06-23T00:22:16.946+10:002012-06-23T00:22:16.946+10:00Does BFS have some timing dependencies with side e...Does BFS have some timing dependencies with side effects?<br /><br />Last help text sentence<br />Optimize very unlikely/likely branches<br />CONFIG_JUMP_LABEL:<br /><br />update of the condition is slower, but those are always very rare.<br /><br />Ralph Ulrich<br />PS: I had also disabled this optionAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-63794052647935094452012-06-22T22:44:09.893+10:002012-06-22T22:44:09.893+10:00@ Con Kolivas & all other on here as well:
I&#...@ Con Kolivas & all other on here as well:<br />I've now spent some days chacking and reverting some config changes I made between 3.3.8 and 3.4.2/3 and testing the resulting kernels whether they run longer then 24h. One of them hardlocked after almost 32h.<br /><br />Then I set CONFIG_JUMP_LABEL back to n (like I had with 3.3.8). And this one, including BFS, ran longer than 49h.<br /><br />Would you consider that this option may harm the BFS or something else in such a way that the machine hardlocks? (gcc version is 4.6.2)<br /><br />Does someone else have experience with this option?<br /><br />Now I'll still need to test the standard scheduler with this option set to y although I don't like to run kernels without BFS. ;-)<br /><br />ManuelAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-60815927834152841392012-06-21T00:01:37.256+10:002012-06-21T00:01:37.256+10:00Recently linux-3.4.4rc-bfs I had some top time ove...Recently linux-3.4.4rc-bfs I had some top time overflows at<br />rcuc/0<br />rcuc/1<br />Is this rpc related? <br /><br />I am just deleting the one patch<br />rpc_pipefs-allow-rpc_purge_list-to-take-a-null-waitq-pointer<br />I see about that and try again ....<br /><br />Ralph UlrichAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-13432380037262163582012-06-18T08:02:10.961+10:002012-06-18T08:02:10.961+10:00Mmmh, there's 3.4.3 out now: Should I wait for...Mmmh, there's 3.4.3 out now: Should I wait for the next lockup (after only ~9h uptime) or just try the new kernel?<br /><br />ManuelAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-6469704299235308349.post-53473303835808893632012-06-18T06:12:43.721+10:002012-06-18T06:12:43.721+10:00My openSUSE kernels predefine DEBUG_KERNEL=y if I ...My openSUSE kernels predefine DEBUG_KERNEL=y if I set EXPERT=y. And there's then already set CONFIG_LOCKDEP_SUPPORT=y, too. <br />Did you mean this one? I don't have a pure "CONFIG_LOCKDEP" in 3.4.2.<br /><br />But this wouldn't help any further anyways, when the _machine_ locks up (difference would be if only the kernel failed). I've even rechecked that there hadn't been any bad temperature issues and the hardware didn't change for months.<br /><br />Thanks, ManuelAnonymousnoreply@blogger.com