On 2017/10/6 上午1:53, Michael Lyle wrote: > On Thu, Oct 5, 2017 at 10:38 AM, Coly Li <i@xxxxxxx> wrote: >> [snip] >> In this test, without bio reorder patches, writeback throughput is >> much faster, you may see the write request number and request merge >> number are also much faster then bio reorder patches. After around 10 >> minutes later, there is no obvious performance difference with/without >> the bio reorder patches. Therefore in this test, with bio reorder >> patches, I observe a worse writeback performance result. >> >> The above tests tell me, to get a better writeback performance with bio >> reorder patches, a specific situation is required (many contiguous dirty >> data on cache device), this situation can only happen in some specific >> of work loads. In general writeback situations, reordering bios by >> waiting does not have significant performance advantage, and even >> performance regression is observed. > > I mean, did you not notice that one of the changes is to limit the > amount of write-issue-merge from the current behavior? It's not > exactly surprising that the initial/peak rate is a bit lower > initially... > > Your test methodology is flawed-- I tried telling you this from the > beginning-- and I'm not convinced at all you understand the point of > the patches. But hey, there's not really any other reviewers on > bcache stuff, so I guess my stuff is blocked forever. ;) Patch 1,2,3 are in my for-next directory and continue for more testing. The new PI controller is simpler and easier to understand with your comprehensive commit log and code comments, and works as expected as a flow controller. We should have it in 4.15, and I will try to make it. Thank you for the great job :-) -- Coly Li
