Thanks for replying. ;)
On 9/11/20 7:01 PM, Ming Lei wrote:
On Fri, Sep 11, 2020 at 11:29:58AM +0800, Jeffle Xu wrote:
Splitted bios of one source bio can be enqueued into different CPU since
the submit_bio() routine can be preempted or fall asleep. However this
behaviour can't work well with iopolling.
Do you have user visible problem wrt. io polling? If yes, can you
provide more details?
No, there's no practical example yet. It's only a hint from the code base.
Currently block iopolling only polls the hardwar queue of the input bio.
If one bio is splitted to several bios, one (bio 1) of which is enqueued
into CPU A, while the others enqueued into CPU B, then the polling of bio 1
will cotinuously poll the hardware queue of CPU A, though the other
splitted bios may be in other hardware queues.
If it is guaranteed that the returned cookie is from bio 1, poll is
supposed to work as expected, since bio 1 is the chained head of these
bios, and the whole fs bio can be thought as done when bio1 .end_bio
is called.
Yes, it is, thanks for your explanation. But except for polling if the
input bio has completed, one of the
important work of polling logic is to reap the completion queue. Let's
say one bio is split into
two bios, bio 1 and bio 2, both of which are enqueued into the same
hardware queue.When polling bio1,
though we have no idea about bio2 at all, the polling logic itself is
still reaping the completion queue of
this hardware queue repeatedly, in which case the polling logic still
stimulates reaping bio2.
Then what if these two split bios enqueued into two different hardware
queue? Let's say bio1 is enqueued
into hardware queue A, while bio2 is enqueued into hardware queue B.
When polling bio1, though the polling
logic is repeatedly reaping the completion queue of hardware queue A, it
doesn't help reap bio2. bio2 is reaped
by IRQ as usual. This certainly works currently, but this behavior may
deviate the polling design? I'm not sure.
In other words, if we can ensure that all split bios are enqueued into
the same hardware queue, then the polling
logic *may* be faster.
The iopolling logic has no idea if the input bio is splitted bio, or if
it has other splitted siblings. Thus ensure that all splitted bios are
enqueued into one CPU at the beginning.
Yeah, that is why io poll can't work on DM.
Exactly I'm interested in dm polling. The polling of bio to dm device
can be mapped into the polling of the
several underlying device. Except for the the design of the cookie,
currently I have not found other blocking
points technically. Please let me know if I missed something.
This is only one RFC patch and it is not complete since dm/mq-scheduler
have not been considered yet. Please let me know if it is on the correct
direction or not.
Besides I have one question on the split routine. Why the split routine
is implemented in a recursive style? Why we can't split the bio one time
and then submit the *already splitted* bios one by one?
Forward progress has to be provided on new splitted bio allocation which
is from same bio_set.
Sorry I can't understand this. Is this a suggestion on how to improving
this patch, or a reply to the question
why the split routine is implemented in a recursive style? Would you
please provide more details?
Thanks,
Ming
Thanks,
Jeffle
