Re: [dm-devel] [PATCH v4 01/11] block: make generic_make_request handle arbitrarily sized bios
On Wed, May 27, 2015 at 01:40:22AM +0100, Alasdair G Kergon wrote: > It does sometimes make a significant difference to device-mapper stacks. > DM only uses it for performance reasons - it can already split bios when > it needs to. I tried to remove merge_bvec_fn from DM several years ago but > couldn't because of the adverse performance impact of lots of splitting > activity. Does it still? Since the move to immutable biovecs the bio splits are pretty cheap now, but I'd really like to see this verified by benchmarks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [dm-devel] [PATCH v4 01/11] block: make generic_make_request handle arbitrarily sized bios
On Wed, May 27, 2015 at 01:40:22AM +0100, Alasdair G Kergon wrote: It does sometimes make a significant difference to device-mapper stacks. DM only uses it for performance reasons - it can already split bios when it needs to. I tried to remove merge_bvec_fn from DM several years ago but couldn't because of the adverse performance impact of lots of splitting activity. Does it still? Since the move to immutable biovecs the bio splits are pretty cheap now, but I'd really like to see this verified by benchmarks. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [dm-devel] [PATCH v4 01/11] block: make generic_make_request handle arbitrarily sized bios
On Wed, May 27, 2015 at 09:06:40AM +1000, Neil Brown wrote: > Because we don't know what the "right" size is. And the "right" size can > change when array reconfiguration happens. In certain configurations today, device-mapper does report back a sensible maximum bio size smaller than would otherwise be used and thereby avoids retrospective splitting. (In tests, the overhead of the duplicate calculation was found to be negligible so we never restructured the code to optimise it away.) > Splitting has to happen somewhere, if only in bio_addpage where it decides to > create a new bio rather than add another page to the current one. So moving > the split to a different level of the stack shouldn't necessarily change the > performance profile. It does sometimes make a significant difference to device-mapper stacks. DM only uses it for performance reasons - it can already split bios when it needs to. I tried to remove merge_bvec_fn from DM several years ago but couldn't because of the adverse performance impact of lots of splitting activity. The overall cost of splitting ought to be less in many (but not necessarily all) cases now as a result of all these patches, so exactly where the best balance lies now needs to be reassessed empirically. It is hard to reach conclusions theoretically because of the complex interplay between the various factors at different levels. Alasdair -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [dm-devel] [PATCH v4 01/11] block: make generic_make_request handle arbitrarily sized bios
On Wed, May 27, 2015 at 09:06:40AM +1000, Neil Brown wrote: Because we don't know what the right size is. And the right size can change when array reconfiguration happens. In certain configurations today, device-mapper does report back a sensible maximum bio size smaller than would otherwise be used and thereby avoids retrospective splitting. (In tests, the overhead of the duplicate calculation was found to be negligible so we never restructured the code to optimise it away.) Splitting has to happen somewhere, if only in bio_addpage where it decides to create a new bio rather than add another page to the current one. So moving the split to a different level of the stack shouldn't necessarily change the performance profile. It does sometimes make a significant difference to device-mapper stacks. DM only uses it for performance reasons - it can already split bios when it needs to. I tried to remove merge_bvec_fn from DM several years ago but couldn't because of the adverse performance impact of lots of splitting activity. The overall cost of splitting ought to be less in many (but not necessarily all) cases now as a result of all these patches, so exactly where the best balance lies now needs to be reassessed empirically. It is hard to reach conclusions theoretically because of the complex interplay between the various factors at different levels. Alasdair -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
