Re: [PATCH 0/8] ARM: mvebu: Add support for RAID6 PQ offloading
On 05/26/2015 07:31 PM, Dan Williams wrote: [ adding Boaz as this discussion has implications for ore_raid ] You're not talking about deprecating it, you're talking about removing it entirely. True, and adding more users makes that removal more difficult. I'm willing to help out on the design and review for this work, I just can't commit to doing the implementation and testing. Hi So for ore_raid, Yes it uses both xor and pq functions, and I expect that to work also after the API changes. That said, I never really cared for the HW offload engines of these APIs. Actually I never met any. On a modern machine I always got the DCE/MMX kick in or one of the other CPU variants. With preliminary testing of XOR I got an almost memory speed for xor (read n pages + write one) So with multy-core CPUs I fail to see how an HW do better, memory caching and all. The PQ was not that far behind. All I need is an abstract API that gives me the best implementation on any ARCH / configuration. Actually the async_tx API is a pain and a sync API would make things simple. I do not use the concurrent async submit, wait later at all. I submit then wait. So anything you change this to, as long as you keep the wonderful dce implementation is good with me, just that the code keeps running after the new API is fine with me. (And the common structures between XOR and PQ was also nice, but I can also use a union, its always either or in ore_raid) Once you make API changes and modify code, CC me I'll run tests good luck Boaz -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mm: kill kmemcheck
On 03/11/2015 03:39 PM, Sasha Levin wrote: On 03/11/2015 08:40 AM, Steven Rostedt wrote: On Wed, 11 Mar 2015 08:34:46 -0400 Sasha Levin sasha.le...@oracle.com wrote: Fair enough. We knew there are existing kmemcheck users, but KASan should be superior both in performance and the scope of bugs it finds. It also shouldn't impose new limitations beyond requiring gcc 4.9.2+. Ouch! OK, then I can't use it. I'm currently compiling with gcc 4.6.3. It will be a while before I upgrade my build farm to something newer. Are you actually compiling new kernels with 4.6.3, or are you using older kernels as well? There's no real hurry to kill kmemcheck right now, but we do want to stop supporting that in favour of KASan. Just my $0.017 for me I wish there was the single config MEM_CHECK and the new or old would be selected automatically depending on enabling factors, for example gcc version, if arch dependent and so on. Thanks Boaz -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [uml/do_xor_speed] WARNING: CPU: 0 PID: 1 at init/main.c:708 do_one_initcall()
On 04/10/2014 09:53 AM, Fengguang Wu wrote: Hi Boaz, I catch the below warning again in git://git.open-osd.org/linux-open-osd.git raid6 OK Thanks. Daa I thought I fixed it but I forgot the obvious problem. I pushed a new tree I think it might be good this time. (finally) Thanks Boaz commit 60e833d86a01ad9d8204a04b8db324106ab50395 Author: Boaz Harrosh bharr...@panasas.com AuthorDate: Thu Jul 19 15:22:37 2012 +0300 Commit: Boaz Harrosh bharr...@panasas.com CommitDate: Tue Apr 8 08:42:14 2014 +0300 RFC: do_xor_speed Broken on UML do to jiffies Remember that hang I reported a while back on UML. Well I'm at it again, and it still hangs and I found why. I have dprinted jiffies and it never advances during the loop at do_xor_speed. There for it is stuck in an endless loop. I have also dprinted current_kernel_time() and it returns the same constant value as well. Note that it does usually work on UML, only during the modprobe of xor.ko while that test is running. It looks like some lucking is preventing the clock from ticking. However ktime_get_ts does work for me so I changed the code as below, so I can work. See how I put several safety guards, to never get hangs again. And I think my time based approach is more accurate then previous system. UML guys please investigate the jiffies issue? what is xor.ko not doing right? Signed-off-by: Boaz Harrosh bharr...@panasas.com [0.383315] WARNING: CPU: 0 PID: 1 at init/main.c:708 do_one_initcall+0x11d/0x136() -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WARNING: CPU: 0 PID: 1 at init/main.c:711 do_one_initcall()
On 11/22/2013 08:02 AM, Yuanhan Liu wrote: Greetings, I got the below dmesg and the first bad commit is commit 20545536cd8ea949c61527b6395ec8c0d2c237b1 Author: Boaz Harrosh bharr...@panasas.com Date: Thu Jul 19 15:22:37 2012 +0300 RFC: do_xor_speed Broken on UML do to jiffies Hi Sir Yuanhan. I understand that you are running exofs_ioctl branch on linux-open-osd.git . Please tell me more why you choose to run this branch it is an experimental pNFS+Ganesha+exofs branch that we are working on around here. It might have problems. Yes this patch has problems, I know. I have it in my tree because I need it if I want to use XOR engine with a UML system. If you do need to run this branch *exofs_ioctl* on your system then it is best you revert this patch. Thanks for the report I think I'll just remove that patch and run with it locally. Cheers Boaz Remember that hang I reported a while back on UML. Well I'm at it again, and it still hangs and I found why. I have dprinted jiffies and it never advances during the loop at do_xor_speed. There for it is stuck in an endless loop. I have also dprinted current_kernel_time() and it returns the same constant value as well. Note that it does usually work on UML, only during the modprobe of xor.ko while that test is running. It looks like some lucking is preventing the clock from ticking. However ktime_get_ts does work for me so I changed the code as below, so I can work. See how I put several safety guards, to never get hangs again. And I think my time based approach is more accurate then previous system. UML guys please investigate the jiffies issue? what is xor.ko not doing right? Signed-off-by: Boaz Harrosh bharr...@panasas.com +--++ | || +--++ | boot_successes | 0 | | boot_failures| 29 | | WARNING:CPU:PID:at_init/main.c:do_one_initcall() | 29 | | initcall_calibrate_xor_blocks_returned_with_preemption_imbalance | 29 | +--++ [0.127025]generic_sse: 148.363 MB/sec [0.127478] xor: using function: prefetch64-sse (152.727 MB/sec) [0.128017] [ cut here ] [0.128531] WARNING: CPU: 0 PID: 1 at init/main.c:711 do_one_initcall+0x105/0x115() [0.129018] initcall calibrate_xor_blocks+0x0/0x144 returned with preemption imbalance [0.130013] Modules linked in: [0.130357] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-11285-gb242bff #91 [0.131013] 88000d0dde00 8161acc5 88000d0dde48 [0.132554] 88000d0dde38 81052de9 81000316 81a77cfd [0.133380] 88000d0dde98 [0.134213] Call Trace: [0.134493] [8161acc5] dump_stack+0x4e/0x7a [0.135017] [81052de9] warn_slowpath_common+0x75/0x8e [0.135654] [81000316] ? do_one_initcall+0x105/0x115 [0.136015] [81a77cfd] ? do_xor_speed+0xdd/0xdd [0.137016] [81052e49] warn_slowpath_fmt+0x47/0x49 [0.137628] [810c8382] ? free_pages+0x51/0x53 [0.138015] [81a77cfd] ? do_xor_speed+0xdd/0xdd [0.138623] [81000316] do_one_initcall+0x105/0x115 [0.139017] [81a59ed6] kernel_init_freeable+0x115/0x19b [0.140016] [81a59707] ? do_early_param+0x88/0x88 [0.140630] [81610ff9] ? rest_init+0xbd/0xbd [0.141016] [81611002] kernel_init+0x9/0xfa [0.141567] [8162a98c] ret_from_fork+0x7c/0xb0 [0.142016] [81610ff9] ? rest_init+0xbd/0xbd [0.143028] ---[ end trace 19b4eab334350767 ]--- [0.143530] atomic64 test passed for x86-64 platform with CX8 and with SSE git bisect start b242bff548c34510fd9b7f0e29b885263dfb8903 5e01dc7b26d9f24f39abace5da98ccbd6a5ceb52 -- git bisect good 5cbb3d216e2041700231bcfc383ee5f8b7fc8b74 # 09:25 20+ 0 Merge branch 'akpm' (patches from Andrew Morton) git bisect good 7e1a1e9378018aeea2c7e8a3dd2ceb1db1523b0b # 09:42 20+ 0 Merge tag 'xfs-for-linus-v3.13-rc1' of git://oss.sgi.com/xfs/xfs git bisect good 4937e2a6f939a41bf811378e80d71f68aa0950c6 # 10:08 20+ 0 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input git bisect good 210e812f036736aeda097d9a6ef84b1f2b334bae # 10:31 20+ 0 perf header: Fix bogus group name git bisect good d5bdaf4f68f0590fc481bca54bcaffeb27b75fca # 10:54 20+ 0 Merge branch 'for-linus
Re: WARNING: CPU: 0 PID: 1 at init/main.c:711 do_one_initcall()
On 11/25/2013 03:25 PM, Yuanhan Liu wrote: Hi Boaz, We are running an 0day kernel testing system. We will test all developers' tree we tracked in our system automatically. And obviously, linux-open-osd is in that list. This system can't tell whether a branch is experimental unless - You put one extra line of Dont-Auto-Build to the head commit log. - the branch name contains experimental, say exofs_ioctl-experimental If both items aren't convenient to you, you can ask us to remove your tree from that list. Then you will never get report like this from us. However, you may lose a chance to find build, boot and performance bug automatically for you ;) --yliu Ha OK very cool. I will remember to put -experimental on the branch name this is fine I will do it ASAP. Thanks so much. Do you have some web based info on the build system? Do you have a place I can see test results and tests summery? Cheers Boaz -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WARNING: CPU: 0 PID: 1 at init/main.c:711 do_one_initcall()
On 11/25/2013 04:15 PM, Richard Weinberger wrote: On Fri, Nov 22, 2013 at 7:02 AM, Yuanhan Liu yuanhan@linux.intel.com wrote: Greetings, I got the below dmesg and the first bad commit is commit 20545536cd8ea949c61527b6395ec8c0d2c237b1 Author: Boaz Harrosh bharr...@panasas.com Date: Thu Jul 19 15:22:37 2012 +0300 RFC: do_xor_speed Broken on UML do to jiffies Remember that hang I reported a while back on UML. Well I'm at it again, and it still hangs and I found why. I have dprinted jiffies and it never advances during the loop at do_xor_speed. There for it is stuck in an endless loop. I have also dprinted current_kernel_time() and it returns the same constant value as well. Note that it does usually work on UML, only during the modprobe of xor.ko while that test is running. It looks like some lucking is preventing the clock from ticking. However ktime_get_ts does work for me so I changed the code as below, so I can work. See how I put several safety guards, to never get hangs again. And I think my time based approach is more accurate then previous system. UML guys please investigate the jiffies issue? what is xor.ko not doing right? This patch never hit my mailbox... Signed-off-by: Boaz Harrosh bharr...@panasas.com Sir Richard I never followed on this patch. Sorry. I do think it is in the right direction, but it has a dev-by-zero problem and a 32 bitness problem. (So I never sent it, beyond the initial query) [It stopped to be very important for me since I stopped using UM very much. Ever since FC17 I'm unable to produce a running image. It just will not boot, an image that a kvm would. So very sad me, but no UML for me anymore.] If you want to investigate. try doing a modprobe xor.ko on a uml and see. since xor.ko is only built on demand for example enabling exofs or object-layout-driver will select it. ,or MD-raid5. Thanks Boaz -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: initcall calibrate_xor_blocks returned with preemption imbalance
On 10/10/2013 06:29 PM, Fengguang Wu wrote: I'm running kernel build/boot/performance tests for *all* the public kernel git trees I'm aware of. If this is not necessary for your tree or some of the branches, sorry I can remove them from the test pool. I can see below: Merge 'open-osd/exofs_ioctl' into devel-hourly-2013101007 OK then there you have it then. Yes exofs_ioctl is a testing branch that I also use with UML. And there for must carry this unfinished patch. Thankyou for the bisect. I will take this crash report and put it on my todo for fixing the xor stuckness. Have a good day Boaz -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: initcall calibrate_xor_blocks returned with preemption imbalance
On 10/10/2013 02:02 AM, Fengguang Wu wrote: Greetings, I got the below dmesg and the first bad commit is Dear Wu This 20545536cd8ea949c61527b6395ec8c0d2c237b1 is from my tree at linux-open-osd.org How did you happen to find it and run with it at all? I have never pushed it to any mailing list or blessed it for release. Yes it has a known problem that I never bothered to fix. I carry it in my own development trees so I can run xor.ko on UML. If it has leaked to any upstream trees, I'm so sorry tell me where you found it and I'll have it removed. I can see below: Merge 'open-osd/exofs_ioctl' into devel-hourly-2013101007 What is devel-hourly and what does exofs_ioctl branch useful for. exofs_ioctl is for NFS-Ganesha pnfs support. It is not good for any other purpose. If you are developing NFS-Ganesha pnfs code feel free to remove this patch, again it is so I can run exofs on UML which uses xor.ko. If you use VMs or HW you do not have this problem. Thanks Boaz commit 20545536cd8ea949c61527b6395ec8c0d2c237b1 Author: Boaz Harrosh bharr...@panasas.com Date: Thu Jul 19 15:22:37 2012 +0300 RFC: do_xor_speed Broken on UML do to jiffies Remember that hang I reported a while back on UML. Well I'm at it again, and it still hangs and I found why. I have dprinted jiffies and it never advances during the loop at do_xor_speed. There for it is stuck in an endless loop. I have also dprinted current_kernel_time() and it returns the same constant value as well. Note that it does usually work on UML, only during the modprobe of xor.ko while that test is running. It looks like some lucking is preventing the clock from ticking. However ktime_get_ts does work for me so I changed the code as below, so I can work. See how I put several safety guards, to never get hangs again. And I think my time based approach is more accurate then previous system. UML guys please investigate the jiffies issue? what is xor.ko not doing right? Signed-off-by: Boaz Harrosh bharr...@panasas.com [0.232004]generic_sse: 6816.333 MB/sec [0.233534] xor: using function: prefetch64-sse (9178.666 MB/sec) [0.235445] [ cut here ] [0.236010] WARNING: CPU: 0 PID: 1 at init/main.c:701 do_one_initcall+0x128/0x138() [0.240041] initcall calibrate_xor_blocks+0x0/0x144 returned with preemption imbalance [0.242872] Modules linked in: [0.244006] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-rc4-wl-02197-g3d5587e #119 [0.246837] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [0.248004] 88000e1e5e00 81a3a6bf 88000e1e5e48 [0.252003] 88000e1e5e38 810c53d5 81000315 8256ff16 [0.255243] 88000e1e5fd8 88000e1e5e98 [0.258537] Call Trace: [0.260010] [81a3a6bf] dump_stack+0x54/0x74 [0.261730] [810c53d5] warn_slowpath_common+0x7f/0x98 [0.263623] [81000315] ? do_one_initcall+0x128/0x138 [0.264006] [8256ff16] ? do_xor_speed+0xe2/0xe2 [0.265785] [810c543a] warn_slowpath_fmt+0x4c/0x4e [0.268007] [811767d9] ? free_pages+0x45/0x47 [0.269751] [8256ff16] ? do_xor_speed+0xe2/0xe2 [0.272006] [81000315] do_one_initcall+0x128/0x138 [0.273843] [82532ed3] kernel_init_freeable+0x159/0x1da [0.276005] [8253274d] ? do_early_param+0x88/0x88 [0.277835] [81a2a057] ? rest_init+0xdb/0xdb [0.280006] [81a2a065] kernel_init+0xe/0xdb [0.281718] [81a4d97c] ret_from_fork+0x7c/0xb0 [0.283485] [81a2a057] ? rest_init+0xdb/0xdb [0.284021] ---[ end trace 3592511960ba24aa ]--- [0.285636] atomic64 test passed for x86-64 platform with CX8 and with SSE git bisect start 3d5587ec7222eebd6d2fa2d4b245ef837a8f36fa 15c03dd4859ab16f9212238f29dd315654aa94f6 -- git bisect good bd1bc39506ad6ce236bf932757d6e3a81b3e3d55 # 09:41 20+ 0 Merge 'regmap/topic/core' into devel-hourly-2013101007 git bisect good f0a6d5852cc8b4e9e518c0426580f0589327e438 # 10:56 20+ 0 Merge 'arm-soc/next/dt' into devel-hourly-2013101007 git bisect good 909dc6fa1f1f42dcdae62b07c4d6b894a392e0d7 # 11:36 20+ 0 Merge 'ipsec-next/testing' into devel-hourly-2013101007 git bisect good 7fb1b0615235b3975def59fbffd0f52c71736bd3 # 11:57 20+ 1 Merge 'arm-soc/next/drivers' into devel-hourly-2013101007 git bisect good ac5fb9846698e9dffc430ab38c1aaefe50a51980 # 12:22 20+ 0 Merge remote-tracking branch 'regulator/topic/optional' into regulator-next git bisect good b9729e9f8d82724c98f13dd358c7b08a4d7de3d2 # 13:31 20+ 3 mtd: nand: pxa3xx_nand: Remove redundant of_match_ptr git bisect bad
Re: RAID5 XOR speed vs RAID6 Q speed (was Re: AVX RAID5 xor checksumming)
On 04/06/2012 11:43 PM, Dan Williams wrote: [adding Boaz since he also made an attempt at fixing this] http://marc.info/?l=linux-crypto-vgerm=13182924450w=2 ...I had meant to follow up on this, but was buried in 'isci' issues. Sorry was traveling. Yes I have an old fix for this. Which I need to cleanup and retest. My original problem was an hang in UML, but I noticed the timing problems as well. Please give me til the end of the week to settle in and come up to speed. [Current patch: http://marc.info/?l=linux-crypto-vgerm=131829242311458w=2] Thanks Boaz On Tue, Apr 3, 2012 at 4:56 PM, Jim Kukunas james.t.kuku...@linux.intel.com wrote: On Tue, Apr 03, 2012 at 11:23:16AM +0100, John Robinson wrote: On 02/04/2012 23:48, Jim Kukunas wrote: On Sat, Mar 31, 2012 at 12:38:56PM +0100, John Robinson wrote: [...] I just noticed in my logs the other day (recent el5 kernel on a Core 2): raid5: automatically using best checksumming function: generic_sse generic_sse: 7805.000 MB/sec raid5: using function: generic_sse (7805.000 MB/sec) [...] raid6: using algorithm sse2x4 (8237 MB/s) I was just wondering how it's possible to do the RAID6 Q calculation faster than the RAID5 XOR calculation - or am I reading this log excerpt wrongly? Out of curiosity, are you running with CONFIG_PREEMPT=y? No. Here's an excerpt from my .config: # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set CONFIG_PREEMPT_BKL=y CONFIG_PREEMPT_NOTIFIERS=y But this is a Xen dom0 kernel, 2.6.18-308.1.1.el5.centos.plusxen. Now, a non-Xen kernel (2.6.18-308.1.1.el5) says: raid5: automatically using best checksumming function: generic_sse generic_sse: 11892.000 MB/sec raid5: using function: generic_sse (11892.000 MB/sec) raid6: int64x1 2644 MB/s raid6: int64x2 3238 MB/s raid6: int64x4 3011 MB/s raid6: int64x8 2503 MB/s raid6: sse2x15375 MB/s raid6: sse2x25851 MB/s raid6: sse2x49136 MB/s raid6: using algorithm sse2x4 (9136 MB/s) Looks like it loses a chunk of performance running as a Xen dom0. Even still, 11892 MB/s for XOR vs 9136 MB/s for XOR+Q - it still seems remarkable that the XOR can't be done several times faster than the Q. Taking a look at do_xor_speed, I see two issues which might be the cause of the disparity you reported. 0) In the RAID5 xor benchmark, we get the current jiffy, then run do_2() until the jiffy increments. This means we could potentially be testing for less than a full jiffy. The RAID6 benchmark handles this by obtaining the current jiffy, then calling cpu_relax() until the jiffy increments, and then running the test. This is addressed by my first patch. 1) The only way I could reproduce your findings of a higher throughput for RAID6 than for RAID5 xor checksumming was with CONFIG_PREEMPT=y. It seems that you encountered this while running as XEN dom0. Currently, we disable preemption during the RAID6 benchmark, but don't in the RAID5 benchmark. This is addressed by my second patch. I've added linux-crypto to the discussion as both of these patches affect code in crypto/ Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
