On Thu, Nov 26, 2009 at 6:45 AM, <heinzm@xxxxxxxxxx> wrote:
> From: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
>
> Neil et al.,
>
> finally got around to creating a followup (interim) patch, which allows
> for changing the xor algorithn at runtime via the message interface,
> hence allowing to test if the xor unrole optimization around the
> supported algorithms is performing better than the assembler
> optimized one in the kernel.
Now that perf is available it would be good to get some comparative
cache utilization statistics on the two approaches. The assembly
routines make an attempt to avoid polluting L2 (however the memcpy's
into the cache do not).
> If we can prove my findings rigth, we could move those into
> the crypto subsystem xor.
>
> Syntax:
> -------
> dmsetup message $MappedDevice 0 xor $Algorithm $Chunks
>
> $MappedDevice = whatever name you picked during creation
> $Algorithm = { "xor_8", "xor_16", "xor_32", "xor_64", "xor_blocks" }
> $Chunks = 2..N # N being the amount of stripes (eg. 5 with 5 disks)
>
> Patch applies to clean mainline git 2.6.32-rc8.
>
> Regards,
> Heinz
>
> Signed-off-by: Heinz Mauelshagen <heinzm@xxxxxxxxxx>
> ---
> drivers/md/Kconfig | 9 +
> drivers/md/Makefile | 2 +
> drivers/md/dm-memcache.c | 301 +++
> drivers/md/dm-memcache.h | 68 +
> drivers/md/dm-raid45.c | 4720 ++++++++++++++++++++++++++++++++++++++++
Where did the investigation of reusing md/raid5.c [1] end up? This
would simultaneously enable hardware accelerated raid6 for dmraid.
--
Dan
[1] http://marc.info/?l=dm-devel&m=124567352518676&w=2
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
