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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 11 Jul 2015 07:17:18 -0400
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	Bob Liu <bob.liu@...cle.com>
CC:	linux-kernel@...r.kernel.org, axboe@...com, hch@...radead.org,
	xen-devel@...ts.xenproject.org, avanzini.arianna@...il.com,
	david.vrabel@...rix.com, marcus.granado@...rix.com,
	roger.pau@...rix.com
Subject: Re: [RESEND PATCH] xen/blkfront: convert to blk-mq APIs

On July 11, 2015 4:18:42 AM EDT, Bob Liu <bob.liu@...cle.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@...il.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@...cle.com>
>> 


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