> On Sep 22, 2016, at 9:44 PM, Ming Lei wrote:
>
>> On Thu, Sep 22, 2016 at 11:17 PM, Jens Axboe wrote:
>>> On 09/22/2016 09:12 AM, Christoph Hellwig wrote:
>>>
On Thu, Sep 22, 2016 at 09:03:56AM -0600, Jens Axboe wrote:
Having to grab a
On Thu, Sep 22, 2016 at 11:17 PM, Jens Axboe wrote:
> On 09/22/2016 09:12 AM, Christoph Hellwig wrote:
>>
>> On Thu, Sep 22, 2016 at 09:03:56AM -0600, Jens Axboe wrote:
>>>
>>> Having to grab a mutex, for instance. We invoke ->queue_rq() with
>>> preemption disabled, so I'd hope
On Thu, Sep 22, 2016 at 11:12 PM, Christoph Hellwig wrote:
> On Thu, Sep 22, 2016 at 09:03:56AM -0600, Jens Axboe wrote:
>> Having to grab a mutex, for instance. We invoke ->queue_rq() with
>> preemption disabled, so I'd hope that would not be the case... What
>> drivers block
On 09/22/2016 10:59 AM, Christoph Hellwig wrote:
On Thu, Sep 22, 2016 at 08:53:00AM -0600, Jens Axboe wrote:
If a driver sets BLK_MQ_F_BLOCKING, it is allowed to block in its
->queue_rq() handler. For that case, blk-mq ensures that we always
calls it from a safe context.
First can you provide
On 09/22/2016 08:59 AM, Christoph Hellwig wrote:
On Thu, Sep 22, 2016 at 08:53:00AM -0600, Jens Axboe wrote:
If a driver sets BLK_MQ_F_BLOCKING, it is allowed to block in its
->queue_rq() handler. For that case, blk-mq ensures that we always
calls it from a safe context.
First can you provide
On Thu, Sep 22, 2016 at 08:53:00AM -0600, Jens Axboe wrote:
> If a driver sets BLK_MQ_F_BLOCKING, it is allowed to block in its
> ->queue_rq() handler. For that case, blk-mq ensures that we always
> calls it from a safe context.
First can you provide a more useful defintion of blocking? Lots of