From: Heinz Mauelshagen <heinzm@redhat.com>
To: device-mapper development <dm-devel@redhat.com>
Cc: linux-raid <linux-raid@vger.kernel.org>
Subject: Re: [PATCH v2 1/1] dm-raid45
Date: Wed, 09 Dec 2009 18:47:20 +0100 [thread overview]
Message-ID: <1260380840.9639.99.camel@o> (raw)
In-Reply-To: <e9c3a7c20912081638w39469743n76b4114b840f1c43@mail.gmail.com>
On Tue, 2009-12-08 at 17:38 -0700, Dan Williams wrote:
> On Thu, Nov 26, 2009 at 6:45 AM, <heinzm@redhat.com> wrote:
> > From: Heinz Mauelshagen <heinzm@redhat.com>
> >
> > 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.
I'd appreciate it.
Do you have any time to spend on this comparison ?
> 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@redhat.com>
> > ---
> > 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.
Not far. Got distracted by other activities and haven't heard back from
Neil after submitting this dm-raid45 patch (which makes it simple to
test various parameter sets w/o reloading mappings).
Heinz
>
> --
> Dan
>
> [1] http://marc.info/?l=dm-devel&m=124567352518676&w=2
>
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2009-12-09 17:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1259243112-28175-1-git-send-email-heinzm@redhat.com>
2009-12-09 0:38 ` [dm-devel] [PATCH v2 1/1] dm-raid45 Dan Williams
2009-12-09 10:43 ` Christoph Hellwig
2009-12-09 17:43 ` Heinz Mauelshagen
2009-12-09 17:47 ` Heinz Mauelshagen [this message]
2009-12-21 16:48 ` [dm-devel] " Dan Williams
2010-01-12 14:44 ` Heinz Mauelshagen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1260380840.9639.99.camel@o \
--to=heinzm@redhat.com \
--cc=dm-devel@redhat.com \
--cc=linux-raid@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).