Re: [PATCH 14/15] nvme-multipath: set QUEUE_FLAG_NOWAIT

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




BLK_MQ_F_BLOCKING is set for nvme-tcp, and the blocking may be done inside
nvme_ns_head_submit_bio(), is that one problem?

The point of BLK_MQ_F_BLOCKING is that ->queue_rq can block, and
because of that it is not called from the submitting context but in
a work queue.  nvme-tcp also sets QUEUE_FLAG_NOWAIT, just like all blk-mq
drivers.

BLK_MQ_F_BLOCKING can be called from submitting context, see
blk_mq_try_issue_directly().

The all drivers setting it have a problem, as the blk-mq core sets
BLK_MQ_F_BLOCKING for all of them.  The right fix would be to not make
it block for REQ_NOWAIT I/O..

Hey Christoph and Ming,

I think that we can remove BLK_MQ_F_BLOCKING setting from nvme-tcp,
the reason that it was set it because lock_sock taken in sendpage is
taking the sk_lock mutex, however given that nvme_tcp_try_send is
protected with the queue send_mutex (which is taken with a
mutex_trylock) we can probably convert it to sendpage_locked...

Let me run it through some tests and get back to you...



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux