On 10/27/20 2:53 AM, Mike Snitzer wrote:
What you detailed there isn't properly modeling what it needs to.
A given dm_target_io could result in quite a few bios (e.g. for
dm-striped we clone each bio for each of N stripes). So the fan-out,
especially if then stacked on N layers of stacked devices, to all the
various hctx at the lowest layers is like herding cats.
But the recursion in block core's submit_bio path makes that challenging
to say the least. So much so that any solution related to enabling
proper bio-based IO polling is going to need a pretty significant
investment in fixing block core (storing __submit_bio()'s cookie during
recursion, possibly storing to driver provided memory location,
e.g. DM initialized bio->submit_cookie pointer to a blk_qc_t within a DM
clone bio's per-bio-data).
SO __submit_bio_noacct would become:
retp = &ret;
if (bio->submit_cookie)
retp = bio->submit_cookie;
*retp = __submit_bio(bio);
Sorry for the late reply. Exactly I missed this point before. IF you
have not started working on this, I'd
like to try to implement this as an RFC.
I think you probably just got caught out by the recursive nature of the bio
submission path -- makes creating a graph of submitted bios and their
associated per-bio-data and generated cookies a mess to track (again,
like herding cats).
Could also be you didn't quite understand the DM code's various
structures.
In any case, the block core changes needed to make bio-based IO polling
work is the main limiting factor right now.
Yes the logic is kind of subtle and maybe what I'm concerned here is
really should be concerned
at the coding phase.
Thanks.
Jeffle Xu
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
