[Drbd-dev] [PATCH v4 01/11] block: make generic_make_request handle arbitrarily sized bios
mlin at kernel.org
Thu May 28 07:54:55 CEST 2015
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
> (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.)
More information about the drbd-dev