[Drbd-dev] [PATCH v4 01/11] block: make generic_make_request handle arbitrarily sized bios

[Ming Lin]

On Wed, May 27, 2015 at 5:36 PM, Alasdair G Kergon <agk at redhat.com> wrote:
> On Wed, May 27, 2015 at 04:42:44PM -0700, Ming Lin wrote:
>> Here are fio results of XFS on a DM stripped target with 2 SSDs + 1 HDD.
>> Does it make sense?
>
> To stripe across devices with different characteristics?

I intended to test it on a 2 sockets server with 10 NVMe drives.
But that server has been busy running other tests.

So I have to run test on a PC which happen to have 2 SSDs + 1 HDD.

>
> Some suggestions.

Thanks for the great detail.
I'm reading to understand.

>
> Prepare 3 kernels.
>   O - Old kernel.
>   M - Old kernel with merge_bvec_fn disabled.
>   N - New kernel.
>
> You're trying to search for counter-examples to the hypothesis that
> "Kernel N always outperforms Kernel O".  Then if you find any, trying
> to show either that the performance impediment is small enough that
> it doesn't matter or that the cases are sufficiently rare or obscure
> that they may be ignored because of the greater benefits of N in much more
> common cases.
>
> (1) You're looking to set up configurations where kernel O performs noticeably
> better than M.  Then you're comparing the performance of O and N in those
> situations.
>
> (2) You're looking at other sensible configurations where O and M have
> similar performance, and comparing that with the performance of N.
>
> In each case you find, you expect to be able to vary some parameter (such as
> stripe size) to show a progression of the effect.
>
> When running tests you've to take care the system is reset into the same
> initial state before each test, so you'll normally also try to include some
> baseline test between tests that should give the same results each time
> and also take the average of a number of runs (while also reporting some
> measure of the variation within each set to make sure that remains low,
> typically a low single digit percentage).
>
> Since we're mostly concerned about splitting, you'll want to monitor
> iostat to see if that gives you enough information to home in on
> suitable configurations for (1).  Failing that, you might need to
> instrument the kernels to tell you the sizes of the bios being
> created and the amount of splitting actually happening.
>
> Striping was mentioned because it forces splitting.  So show the progression
> from tiny stripes to huge stripes.  (Ensure all the devices providing the
> stripes have identical characteristics, but you can test with slow and
> fast underlying devices.)
>
> You may also want to test systems with a restricted amount of available
> memory to show how the splitting via worker thread performs.  (Again,
> instrument to prove the extent to which the new code is being exercised.)
>
> Alasdair
>