From: Bob Liu <bob.liu@oracle.com>
To: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: xen-devel@lists.xen.org, david.vrabel@citrix.com,
linux-kernel@vger.kernel.org, konrad.wilk@oracle.com,
felipe.franciosi@citrix.com, axboe@fb.com, hch@infradead.org,
avanzini.arianna@gmail.com, rafal.mielniczuk@citrix.com,
boris.ostrovsky@oracle.com, jonathan.davies@citrix.com
Subject: Re: [PATCH v3 7/9] xen/blkback: separate ring information out of struct xen_blkif
Date: Mon, 19 Oct 2015 18:03:48 +0800 [thread overview]
Message-ID: <5624C004.2040901@oracle.com> (raw)
In-Reply-To: <5624B997.4020907@citrix.com>
On 10/19/2015 05:36 PM, Roger Pau Monné wrote:
> El 10/10/15 a les 6.08, Bob Liu ha escrit:
>> On 10/05/2015 10:55 PM, Roger Pau Monné wrote:
>>> The same for the pool of persistent grants, it should be per-device and
>>> not per-ring.
>>>
>>> And I think this issue is far worse than the others, because a frontend
>>> might use a persistent grant on different queues, forcing the backend
>>> map the grant several times for each queue, this is not acceptable IMO.
>>>
>>
>> Hi Roger,
>>
>> I realize it would make things complicate if making persistent grant per-device instead of per-queue.
>> Extra locks are required to protect the per-device pool on both blkfront and blkback.
>
> Yes, I realize this, but without having at least a prototype it's hard
> to tell if contention is going to be a problem or not. We already use a
> red-black tree to store persistent grants, which should be quite fast
> when performing searches.
>
> IMHO, we are doing things backwards, we should have investigated first
> if using per-device was a problem, and if it indeed was a problem then
> move to per-queue. Using per-device just required adding locks around
> the functions to get/put grants and friends, leaving the data structures
> untouched (per-device).
>
>> AFAIR, there was a discussion before about dropping persistent grant map at all.
>> The only reason we left this feature was backward compatibility.
>> So that I think we should not complicate xen-block code any more because of a going to be dropped feature.
>>
>> How about disable feature-persistent if multi-queue was used?
>
> This is not what we have done in the past, also there's no way for
> blkback to tell the frontend that persistent grants and multiqueue
> cannot be used at the same time. Blkback puts all supported features on
> xenstore before knowing anything about the frontend.
>
> Also, if you want to do it per-queue instead of per-device the limits
> need to be properly adjusted, not just the persistent grants one, but
> also the queue of cached free pages. This also implies that each queue
> it's going to have it's own LRU and purge task.
>
Okay, then I'll update with a per-device version.
For blkfront there would be two locks used, one for per-device and the other for per-ring.
For blkback, an new lock would be added to protect the red-black tree e.g. in add_persistent_gnt().
--
Regards,
-Bob
next prev parent reply other threads:[~2015-10-19 10:04 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-05 12:39 [PATCH v3 0/9] xen-block: support multi hardware-queues/rings Bob Liu
2015-09-05 12:39 ` [PATCH v3 1/9] xen-blkfront: convert to blk-mq APIs Bob Liu
2015-09-23 20:31 ` Konrad Rzeszutek Wilk
2015-09-23 21:12 ` Konrad Rzeszutek Wilk
2015-09-05 12:39 ` [PATCH v3 2/9] xen-block: add document for mutli hardware queues/rings Bob Liu
2015-09-23 20:32 ` Konrad Rzeszutek Wilk
2015-10-02 16:04 ` Roger Pau Monné
2015-10-02 16:12 ` [Xen-devel] " Wei Liu
2015-10-02 16:22 ` Roger Pau Monné
2015-10-02 23:55 ` Bob Liu
2015-09-05 12:39 ` [PATCH v3 3/9] xen/blkfront: separate per ring information out of device info Bob Liu
2015-10-02 17:02 ` Roger Pau Monné
2015-10-03 0:34 ` Bob Liu
2015-10-05 15:17 ` Roger Pau Monné
2015-10-10 8:30 ` Bob Liu
2015-10-19 9:42 ` Roger Pau Monné
2015-09-05 12:39 ` [PATCH v3 4/9] xen/blkfront: pseudo support for multi hardware queues/rings Bob Liu
2015-10-05 10:52 ` Roger Pau Monné
2015-10-07 10:28 ` Bob Liu
2015-09-05 12:39 ` [PATCH v3 5/9] xen/blkfront: convert per device io_lock to per ring ring_lock Bob Liu
2015-10-05 14:13 ` Roger Pau Monné
2015-10-07 10:34 ` Bob Liu
2015-09-05 12:39 ` [PATCH v3 6/9] xen/blkfront: negotiate the number of hw queues/rings with backend Bob Liu
2015-10-05 14:40 ` Roger Pau Monné
2015-10-07 10:39 ` Bob Liu
2015-10-07 11:46 ` Roger Pau Monné
2015-10-07 12:19 ` Bob Liu
2015-09-05 12:39 ` [PATCH v3 7/9] xen/blkback: separate ring information out of struct xen_blkif Bob Liu
2015-10-05 14:55 ` Roger Pau Monné
2015-10-07 10:41 ` Bob Liu
2015-10-10 4:08 ` Bob Liu
2015-10-19 9:36 ` Roger Pau Monné
2015-10-19 10:03 ` Bob Liu [this message]
2015-10-05 14:55 ` Roger Pau Monné
2015-09-05 12:39 ` [PATCH v3 8/9] xen/blkback: pseudo support for multi hardware queues/rings Bob Liu
2015-10-05 15:08 ` Roger Pau Monné
2015-10-07 10:50 ` Bob Liu
2015-10-07 11:49 ` Roger Pau Monné
2015-09-05 12:39 ` [PATCH v3 9/9] xen/blkback: get number of hardware queues/rings from blkfront Bob Liu
2015-10-05 15:15 ` Roger Pau Monné
2015-10-07 10:54 ` Bob Liu
2015-10-02 9:57 ` [PATCH v3 0/9] xen-block: support multi hardware-queues/rings Rafal Mielniczuk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5624C004.2040901@oracle.com \
--to=bob.liu@oracle.com \
--cc=avanzini.arianna@gmail.com \
--cc=axboe@fb.com \
--cc=boris.ostrovsky@oracle.com \
--cc=david.vrabel@citrix.com \
--cc=felipe.franciosi@citrix.com \
--cc=hch@infradead.org \
--cc=jonathan.davies@citrix.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rafal.mielniczuk@citrix.com \
--cc=roger.pau@citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).