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
Attachment:
signature.asc
Description: PGP signature
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
