On Wed, Apr 14, 2021 at 04:38:25PM +0800, JeffleXu wrote: > > > On 4/12/21 5:38 PM, Christoph Hellwig wrote: > > On Thu, Apr 01, 2021 at 10:19:26AM +0800, Ming Lei wrote: > >> From: Jeffle Xu <jefflexu@xxxxxxxxxxxxxxxxx> > >> > >> This method can be used to check if bio-based device supports IO polling > >> or not. For mq devices, checking for hw queue in polling mode is > >> adequate, while the sanity check shall be implementation specific for > >> bio-based devices. For example, dm device needs to check if all > >> underlying devices are capable of IO polling. > >> > >> Though bio-based device may have done the sanity check during the > >> device initialization phase, cacheing the result of this sanity check > >> (such as by cacheing in the queue_flags) may not work. Because for dm > >> devices, users could change the state of the underlying devices through > >> '/sys/block/<dev>/io_poll', bypassing the dm device above. In this case, > >> the cached result of the very beginning sanity check could be > >> out-of-date. Thus the sanity check needs to be done every time 'io_poll' > >> is to be modified. > > > > I really don't think thi should be a method, and I really do dislike > > how we have all this "if (is_mq)" junk. Why can't we have a flag on > > the gendisk that signals if the device can support polling that > > is autoamtically set for blk-mq and as-needed by bio based drivers? > > That would consume one more bit of queue->queue_flags. > > Besides, DM/MD is somehow special here that when one of the underlying > devices is disabled polling through '/sys/block/<dev>/io_poll', > currently there's no mechanism notifying the above MD/DM to clear the > previously set queue_flags. Thus the outdated queue_flags still > indicates this DM/MD is capable of polling, while in fact one of the > underlying device has been disabled for polling. Right, just like there isn't queue limit progagation. Another blocker could be that bio based queue doesn't support queue freezing. > > Mike had ever suggested that we can trust the queue_flag, and clear the > outdated queue_flags when later the IO submission or polling routine > finally finds that the device is not capable of polling. Currently > submit_bio_checks() will silently clear the REQ_HIPRI flag and still > submit the bio when the device is actually not capable of polling. To > fix the issue, could we break the submission and return an error code in > submit_bio_checks() if the device is not capable of polling when > submitting HIPRI bio? I think we may just leave it alone, if underlying queue becomes not pollable, the bio still can be submitted & completed via IRQ, just not efficient enough. Thanks, Ming
