[PATCH 3/8] block: don't update BLK_FEAT_POLL in __blk_mq_update_nr_hw_queues
Nilay Shroff
nilay at linux.ibm.com
Tue Jan 7 01:23:40 PST 2025
On 1/7/25 1:51 PM, Christoph Hellwig wrote:
> On Tue, Jan 07, 2025 at 12:27:35PM +0530, Nilay Shroff wrote:
>> As discussed in another thread with Damien, shouldn't we need to
>> move bdev_can_poll() to header file?
>
> Well, if it was needed I would have done it, otherwise the code wouldn't
> compile, would it?
>
I think, there won't be compile error because if we look at the show function
for "io_poll" attribute under sysfs, then I see it evaluates the queue limits
feature flag BLK_FEAT_POLL and returns the value.
>> We also need to use this
>> function while reading sysfs attribute "io-poll", no?
>
> This now reports polling support when the driver declared it but
> later resized the number of queues to have no queues left. Which I
> think is a fine tradeoff if you do that.
>
When I applied you patch on my system and access io_poll attribute
of one of my nvme disk, I see it returns 1, though I didn't configure
poll queue for the disk. With this patch, as we're now always setting
BLK_FEAT_POLL (under blk_mq_alloc_queue()) it return 1. So when I haven't
configured poll queue for NVMe driver, shouldn't it return 0 when I access
/sys/block/nvmeXnY/queue/io_poll ?
Thanks,
--Nilay
More information about the Linux-nvme
mailing list