Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752702AbbBSCFk (ORCPT ); Wed, 18 Feb 2015 21:05:40 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:28005 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752412AbbBSCFi (ORCPT ); Wed, 18 Feb 2015 21:05:38 -0500 Message-ID: <54E544CC.4080007@oracle.com> Date: Thu, 19 Feb 2015 10:05:00 +0800 From: Bob Liu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Felipe Franciosi CC: "'Konrad Rzeszutek Wilk'" , Roger Pau Monne , "xen-devel@lists.xen.org" , David Vrabel , "linux-kernel@vger.kernel.org" , "axboe@fb.com" , "hch@infradead.org" , "avanzini.arianna@gmail.com" Subject: Re: [PATCH 04/10] xen/blkfront: separate ring information to an new struct References: <1423988345-4005-1-git-send-email-bob.liu@oracle.com> <1423988345-4005-5-git-send-email-bob.liu@oracle.com> <54E4CBD1.1000802@citrix.com> <20150218173746.GF8152@l.oracle.com> <9F2C4E7DFB7839489C89757A66C5AD629EB997@AMSPEX01CL03.citrite.net> In-Reply-To: <9F2C4E7DFB7839489C89757A66C5AD629EB997@AMSPEX01CL03.citrite.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4211 Lines: 101 On 02/19/2015 02:08 AM, Felipe Franciosi wrote: >> -----Original Message----- >> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] >> Sent: 18 February 2015 17:38 >> To: Roger Pau Monne >> Cc: Bob Liu; xen-devel@lists.xen.org; David Vrabel; linux- >> kernel@vger.kernel.org; Felipe Franciosi; axboe@fb.com; hch@infradead.org; >> avanzini.arianna@gmail.com >> Subject: Re: [PATCH 04/10] xen/blkfront: separate ring information to an new >> struct >> >> On Wed, Feb 18, 2015 at 06:28:49PM +0100, Roger Pau Monn? wrote: >>> El 15/02/15 a les 9.18, Bob Liu ha escrit: >>>> A ring is the representation of a hardware queue, this patch >>>> separate ring information from blkfront_info to an new struct >>>> blkfront_ring_info to make preparation for real multi hardware queues >> supporting. >>>> >>>> Signed-off-by: Arianna Avanzini >>>> Signed-off-by: Bob Liu >>>> --- >>>> drivers/block/xen-blkfront.c | 403 >>>> +++++++++++++++++++++++-------------------- >>>> 1 file changed, 218 insertions(+), 185 deletions(-) >>>> >>>> diff --git a/drivers/block/xen-blkfront.c >>>> b/drivers/block/xen-blkfront.c index 5a90a51..aaa4a0e 100644 >>>> --- a/drivers/block/xen-blkfront.c >>>> +++ b/drivers/block/xen-blkfront.c >>>> @@ -102,23 +102,15 @@ MODULE_PARM_DESC(max, "Maximum amount >> of >>>> segments in indirect requests (default #define BLK_RING_SIZE >>>> __CONST_RING_SIZE(blkif, PAGE_SIZE) >>>> >>>> /* >>>> - * We have one of these per vbd, whether ide, scsi or 'other'. >>>> They >>>> - * hang in private_data off the gendisk structure. We may end up >>>> - * putting all kinds of interesting stuff here :-) >>>> + * Per-ring info. >>>> + * A blkfront_info structure can associate with one or more >>>> + blkfront_ring_info, >>>> + * depending on how many hardware queues supported. >>>> */ >>>> -struct blkfront_info >>>> -{ >>>> +struct blkfront_ring_info { >>>> spinlock_t io_lock; >>>> - struct mutex mutex; >>>> - struct xenbus_device *xbdev; >>>> - struct gendisk *gd; >>>> - int vdevice; >>>> - blkif_vdev_t handle; >>>> - enum blkif_state connected; >>>> int ring_ref; >>>> struct blkif_front_ring ring; >>>> unsigned int evtchn, irq; >>>> - struct request_queue *rq; >>>> struct work_struct work; >>>> struct gnttab_free_callback callback; >>>> struct blk_shadow shadow[BLK_RING_SIZE]; @@ -126,6 +118,22 @@ >>>> struct blkfront_info >>>> struct list_head indirect_pages; >>>> unsigned int persistent_gnts_c; >>>> unsigned long shadow_free; >>>> + struct blkfront_info *info; >>> >>> AFAICT you seem to have a list of persistent grants, indirect pages >>> and a grant table callback for each ring, isn't this supposed to be >>> shared between all rings? >>> >>> I don't think we should be going down that route, or else we can hoard >>> a large amount of memory and grants. >> >> It does remove the lock that would have to be accessed by each ring thread to >> access those. Those values (grants) can be limited to be a smaller value such >> that the overall number is the same as it was with the previous version. As in: >> each ring has = MAX_GRANTS / nr_online_cpus(). >>> > > We should definitely be concerned with the amount of memory consumed on the backend for each plugged virtual disk. We have faced several problems in XenServer around this area before; it drastically affects VBD scalability per host. > Right, so we have to keep both the lock and the amount of memory consumed in mind. > This makes me think that all the persistent grants work was done as a workaround while we were facing several performance problems around concurrent grant un/mapping operations. Given all the recent submissions made around this (grant ops) area, is this something we should perhaps revisit and discuss whether we want to continue offering persistent grants as a feature? > Agree, Life would be easier if we can remove the persistent feature. -- Regards, -Bob -- 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/