- Apr 21, 2015
-
-
Markus Stockhausen authored
v3: s-o-b comment, explanation of performance and descision for the start/stop implementation Implementing rmw functionality for RAID6 requires optimized syndrome calculation. Up to now we can only generate a complete syndrome. The target P/Q pages are always overwritten. With this patch we provide a framework for inplace P/Q modification. In the first place simply fill those functions with NULL values. xor_syndrome() has two additional parameters: start & stop. These will indicate the first and last page that are changing during a rmw run. That makes it possible to avoid several unneccessary loops and speed up calculation. The caller needs to implement the following logic to make the functions work. 1) xor_syndrome(disks, start, stop, ...): "Remove" all data of source blocks inside P/Q between (and including) start and end. 2) modify any block with start <= block <= stop 3) xor_syndrome(disks, start, stop, ...): "Reinsert" all data of source blocks into P/Q between (and including) start and end. Pages between start and stop that won't be changed should be filled with a pointer to the kernel zero page. The reasons for not taking NULL pages are: 1) Algorithms cross the whole source data line by line. Thus avoid additional branches. 2) Having a NULL page avoids calculating the XOR P parity but still need calulation steps for the Q parity. Depending on the algorithm unrolling that might be only a difference of 2 instructions per loop. The benchmark numbers of the gen_syndrome() functions are displayed in the kernel log. Do the same for the xor_syndrome() functions. This will help to analyze performance problems and give an rough estimate how well the algorithm works. The choice of the fastest algorithm will still depend on the gen_syndrome() performance. With the start/stop page implementation the speed can vary a lot in real life. E.g. a change of page 0 & page 15 on a stripe will be harder to compute than the case where page 0 & page 1 are XOR candidates. To be not to enthusiatic about the expected speeds we will run a worse case test that simulates a change on the upper half of the stripe. So we do: 1) calculation of P/Q for the upper pages 2) continuation of Q for the lower (empty) pages Signed-off-by:
Markus Stockhausen <stockhausen@collogia.de> Signed-off-by:
NeilBrown <neilb@suse.de>
-
- Dec 13, 2012
-
-
Yuanhan Liu authored
sse and avx2 stuff only exist on x86 arch, and we don't need to build altivec on x86. And we can do that at lib/raid6/Makefile. Proposed-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
Yuanhan Liu <yuanhan.liu@linux.intel.com> Reviewed-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
Jim Kukunas <james.t.kukunas@linux.intel.com> Signed-off-by:
NeilBrown <neilb@suse.de>
-
- Aug 11, 2010
-
-
NeilBrown authored
Rename raid6/raid6x86.h to raid6/x86.h and modify some comments. Signed-off-by:
NeilBrown <neilb@suse.de>
-
- Aug 10, 2010
-
-
David Woodhouse authored
Linus asks 'why "raid6" twice?'. No reason. Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com>
-
- Oct 29, 2009
-
-
David Woodhouse authored
We'll want to use these in btrfs too. Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com>
-
- Mar 31, 2009
-
-
Dan Williams authored
Move the raid6 data processing routines into a standalone module (raid6_pq) to prepare them to be called from async_tx wrappers and other non-md drivers/modules. This precludes a circular dependency of raid456 needing the async modules for data processing while those modules in turn depend on raid456 for the base level synchronous raid6 routines. To support this move: 1/ The exportable definitions in raid6.h move to include/linux/raid/pq.h 2/ The raid6_call, recovery calls, and table symbols are exported 3/ Extra #ifdef __KERNEL__ statements to enable the userspace raid6test to compile Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
NeilBrown <neilb@suse.de>
-
Atsushi SAKAI authored
Hello, I found a typo Bosto"m" in FSF address. And I am checking around linux source code. Here is the only place which uses Bosto"m" (not Boston). Signed-off-by:
Atsushi SAKAI <sakaia@jp.fujitsu.com> Signed-off-by:
NeilBrown <neilb@suse.de>
-
- Oct 29, 2007
-
-
Al Viro authored
Don't undef __i386__/__x86_64__ in uml anymore, make sure that (few) places that required adjusting the ifdefs got those. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- Mar 01, 2007
-
-
H. Peter Anvin authored
- Use kernel_fpu_begin() and kernel_fpu_end() - Use boot_cpu_has() for feature testing even in userspace Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
Neil Brown <neilb@suse.de> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- Apr 16, 2005
-
-
Linus Torvalds authored
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-