Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1182135 > unrolled thread

Re: [RESEND PATCH] xen/blkfront: convert to blk-mq APIs

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RESEND PATCH] xen/blkfront: convert to blk-mq APIs Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> - 2015-07-11 13:20 +0200
    Re: [RESEND PATCH] xen/blkfront: convert to blk-mq APIs Christoph Hellwig <hch@infradead.org> - 2015-07-11 13:30 +0200
      Re: [RESEND PATCH] xen/blkfront: convert to blk-mq APIs Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> - 2015-07-11 14:00 +0200

#1182135 — Re: [RESEND PATCH] xen/blkfront: convert to blk-mq APIs

On July 11, 2015 4:18:42 AM EDT, Bob Liu <bob.liu@oracle.com> wrote:
>
>On 07/11/2015 03:57 AM, Konrad Rzeszutek Wilk wrote:
>> On Mon, Jul 06, 2015 at 05:56:48PM +0800, Bob Liu wrote:
>>> From: Arianna Avanzini <avanzini.arianna@gmail.com>
>>>
>>> This patch converts xen-blkfront driver to use the block multiqueue
>APIs.
>>> Only one hardware queue is used now, so there is no performance
>change.
>>>
>>> The legacy non-mq code was deleted completely which is the same as
>other drivers
>>> like virtio, mtip, and nvme.
>>>
>>> Also dropped unnecessary holding of info->io_lock when calling into
>blk-mq APIs.
>> 
>> Yeey!
>> 
>> Two points:
>> 
>>  - The io_lock is now used to guard against concurrent access to the
>ring.
>>    We should rename it to 'ring_lock'.
>> 
>
>Sure.
>
>>  - The kick_pending_request_queues should have an extra argument -
>'bool locked'.
>>    This is so that you don't drop and immediately grab the lock from
>the blkif_interrupt.
>> 
>
>Then where to drop the lock?

The 'locked' parameter can be used to tell the function to not take the lock.

But it would drop the lock in both cases.
>
>In kick_pending_request_queues(), the lock have to be dropped before
>calling blk_mq_start_stopped_hw_queues().
>
> static void kick_pending_request_queues(struct blkfront_info *info)
> {
>+	unsigned long flags;
>+
>+	spin_lock_irqsave(&info->io_lock, flags);
> 	if (!RING_FULL(&info->ring)) {
>-		/* Re-enable calldowns. */
>-		blk_start_queue(info->rq);
>-		/* Kick things off immediately. */
>-		do_blkif_request(info->rq);
>+		spin_unlock_irqrestore(&info->io_lock, flags);
>+		blk_mq_start_stopped_hw_queues(info->rq, true);
>+		return;
> 	}
>
>>    See:
>> 
>>> @@ -1243,9 +1243,8 @@ static irqreturn_t blkif_interrupt(int irq,
>void *dev_id)
>>>  	} else
>>>  		info->ring.sring->rsp_event = i + 1;
>>>  
>>> -	kick_pending_request_queues(info);
>>> -
>>>  	spin_unlock_irqrestore(&info->io_lock, flags);
>>> +	kick_pending_request_queues(info);
>>>  
>>>  	return IRQ_HANDLED;
>>>  }
>> 
>> Otherwise Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1182137

On Sat, Jul 11, 2015 at 07:17:18AM -0400, Konrad Rzeszutek Wilk wrote:
> The 'locked' parameter can be used to tell the function to not take the lock.
> 
> But it would drop the lock in both cases.

Konrad,

no conditional locking please.  Split the functionality up in multiple
functions if you may call with or without a lock held.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1182140

On July 11, 2015 7:23:38 AM EDT, Christoph Hellwig <hch@infradead.org> wrote:
>On Sat, Jul 11, 2015 at 07:17:18AM -0400, Konrad Rzeszutek Wilk wrote:
>> The 'locked' parameter can be used to tell the function to not take
>the lock.
>> 
>> But it would drop the lock in both cases.
>
>Konrad,
>
>no conditional locking please.  Split the functionality up in multiple
>functions if you may call with or without a lock held.

That would work nicely too. Thanks!

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web