linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Bob Liu <bob.liu@oracle.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 11:36:23 +0200	[thread overview]
Message-ID: <5624B997.4020907@citrix.com> (raw)
In-Reply-To: <56188F4A.3060802@oracle.com>

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.

Roger.


  reply	other threads:[~2015-10-19  9:36 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é [this message]
2015-10-19 10:03         ` Bob Liu
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=5624B997.4020907@citrix.com \
    --to=roger.pau@citrix.com \
    --cc=avanzini.arianna@gmail.com \
    --cc=axboe@fb.com \
    --cc=bob.liu@oracle.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=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).