Re: [dm-devel] [PATCH v2 1/1] dm-raid45

Re: [dm-devel] [PATCH v2 1/1] dm-raid45

[Dan Williams]

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.  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.

--
Dan

[1] http://marc.info/?l=dm-devel&m=124567352518676&w=2
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [dm-devel] [PATCH v2 1/1] dm-raid45

[Christoph Hellwig]

On Tue, Dec 08, 2009 at 05:38:06PM -0700, Dan Williams wrote:
> Where did the investigation of reusing md/raid5.c [1] end up?  This
> would simultaneously enable hardware accelerated raid6 for dmraid.

Yes, adding different raid code to dm is a bad idea, even more so after
Neil showed a useful prototype of reusing the md code.

Re: [PATCH v2 1/1] dm-raid45

[Heinz Mauelshagen]

Please don't forget the point about 3rd party tests of the xor
optimization in dm-reaid45 vs. the crypto one. I want that to be tested
in order to prove, if we got an advantage over the crypto implementation
or not.

Heinz

On Wed, 2009-12-09 at 05:43 -0500, Christoph Hellwig wrote:
> On Tue, Dec 08, 2009 at 05:38:06PM -0700, Dan Williams wrote:
> > Where did the investigation of reusing md/raid5.c [1] end up?  This
> > would simultaneously enable hardware accelerated raid6 for dmraid.
> 
> Yes, adding different raid code to dm is a bad idea, even more so after
> Neil showed a useful prototype of reusing the md code.
> 

Re: [PATCH v2 1/1] dm-raid45

[Heinz Mauelshagen]

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

Re: [dm-devel] [PATCH v2 1/1] dm-raid45

[Dan Williams]

On Wed, Dec 9, 2009 at 10:47 AM, Heinz Mauelshagen <heinzm@redhat.com> wrote:
> 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 ?
>

I can give it a shot.  The easiest way to test would be to export your
versions via a struct xor_block_template.  However, the question I
have is how do your macros differ from the existing ones in
include/asm-generic/xor.h?  Can we achieve the same effect by
extending the ones in include/asm-generic/xor.h to do up to 8 at a
time?

Thanks,
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [dm-devel] [PATCH v2 1/1] dm-raid45

[Heinz Mauelshagen]

On Mon, 2009-12-21 at 09:48 -0700, Dan Williams wrote:
> On Wed, Dec 9, 2009 at 10:47 AM, Heinz Mauelshagen <heinzm@redhat.com> wrote:
> > 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 ?
> >
> 
> I can give it a shot.

Thanks.

>  The easiest way to test would be to export your
> versions via a struct xor_block_template.

Yes, but my recent dm-raid45 patch on dm-devel allows for selection of
the xor routine being used and its parameters..

Fiddling the macros into xor_block_template structs would allow for
testing them with other callers...

>  However, the question I
> have is how do your macros differ from the existing ones in
> include/asm-generic/xor.h?

Those xor data from multiple blocks via sequenced single xor operations
whereas mine does them in one go.

> Can we achieve the same effect by
> extending the ones in include/asm-generic/xor.h to do up to 8 at a
> time?

I don't think so but that's one question to answer.

Thanks,
Heinz

> 
> Thanks,
> Dan
> 
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel