Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
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 >