[dm-devel] [LSF/MM TOPIC] block: extend generic biosets to allow per-device frontpad

[NeilBrown]

On Mon, Jan 29 2018, Mike Snitzer wrote:

> I'd like to enable bio-based DM to _not_ need to clone bios.  But to do
> so each bio-based DM target's required per-bio-data would need to be
> provided by upper layer biosets (as opposed to the bioset DM currently
> creates).
>
> So my thinking is that all system-level biosets (e.g. fs_bio_set,
> blkdev_dio_pool) would redirect to a device specific variant bioset IFF
> the underlying device advertises the need for a specific per-bio-data
> payload to be provided.
>
> I know this _could_ become a rathole but I'd like to avoid reverting DM
> back to the days of having to worry about managing mempools for the
> purpose of per-io allocations.  I've grown spoiled by the performance
> and elegance that comes with having the bio and per-bio-data allocated
> from the same bioset.
>
> Thoughts?

md/raid0 remaps each bio and passes it directly down to one of several
devices.
I think your scheme would mean that it would need to clone each bio to
make sure it is from the correctly sized pool.

I suspect it could be made to work though.

1/ have a way for the driver receiving a bio to discover how much
   frontpad was allocated.
2/ require drivers to accept bios with any size of frontpad, but a
   fast-path is taken if it is already big enough.
3/ allow a block device to advertise it's preferred frontpad.
4/ make sure your config-change-notification mechanism can communicate
   changes to this number.
5/ gather statistics on what percentage of bios have a too-small
   frontpad.

Then start modifying places that allocate bios to use the hint,
and when benchmarks show the percentage is high - use it to encourage
other people to allocate better bios.

NeilBrown
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20180202/0da09b08/attachment.sig>