linux-kernel - Re: [PATCH v3] dm stripe: implement merge method

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110308164849.GA5692@redhat.com>
Date:	Tue, 8 Mar 2011 11:48:49 -0500
From:	Mike Snitzer <snitzer@...hat.com>
To:	Mustafa Mesanovic <mume@...ux.vnet.ibm.com>
Cc:	Neil Brown <neilb@...e.de>, akpm@...ux-foundation.org,
	dm-devel@...hat.com, cotte@...ibm.com, heiko.carstens@...ibm.com,
	linux-kernel@...r.kernel.org, ehrhardt@...ux.vnet.ibm.com,
	"Alasdair G. Kergon" <agk@...hat.com>,
	Jeff Moyer <jmoyer@...hat.com>
Subject: Re: [PATCH v3] dm stripe: implement merge method

On Tue, Mar 08 2011 at  5:29am -0500,
Mustafa Mesanovic <mume@...ux.vnet.ibm.com> wrote:

> On 03/08/2011 03:21 AM, Mike Snitzer wrote:
>
> >Here is a revised version of your patch that uses the relatively new
> >stripe_map_sector(), removes an unnecessary cast, and a few other
> >cleanups.
> >
> >This v3 should work as well as your v2 but should be suitable for
> >upstream inclusion -- authorship of the change is still attributed to
> >you as I only updated the code slightly.  I'd appreciate it if you could
> >verify your config still performs as expected.
>
> Mike,
> 
> your changes are working well and performing even a bit better.

Good to know.

> Are there any further comments from others, or can consider putting it
> upstream.

I chatted with Alasdair and one concern he had was: does the existence
of stripe_merge() ever hurt due to the fact that stripe_map_sector() is
performed twice (once for .merge and again for .map)?  May be that a
really small chuck_size proves to be more problematic but using a small
chunk_size generally isn't productive to begin with.

In any case, it clearly helps your workload.

Could you explain your config in more detail?
- what is your chunk_size?
- how many stripes (how many mpath devices)?
- what is the performance, of your test workload, of a single underlying
  mpath device?

And, in particular, what is your test workload?
- What is the nature of your IO (are you using a particular tool)?
- Are you using AIO?
- How many threads?
- Are you driving deep queue depths? Etc.

I have various configs that I'll be testing to help verify the benefit.
The only other change Alasdair request is that the target version should
be bumped to 1.4 (rather than 1.3.2).

Given that I can put some time to this now: we should be able to sort
all this out for upstream inclusion in 2.6.39.

Thanks,
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/