From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: blkback global resources Date: Mon, 26 Mar 2012 12:56:44 -0400 Message-ID: <20120326165644.GA12494@phenom.dumpdata.com> References: <4F70ADD4020000780007AF3B@nat28.tlf.novell.com> <1332778808.26550.23.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1332778808.26550.23.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Wei Liu , Jan Beulich , xen-devel List-Id: xen-devel@lists.xenproject.org On Mon, Mar 26, 2012 at 05:20:08PM +0100, Ian Campbell wrote: > On Mon, 2012-03-26 at 16:56 +0100, Jan Beulich wrote: > > All the resources allocated based on xen_blkif_reqs are global in > > blkback. While (without having measured anything) I think that this > > is bad from a QoS perspective (not the least implied from a warning > > issued by Citrix'es multi-page-ring patches: > > > > if (blkif_reqs < BLK_RING_SIZE(order)) > > printk(KERN_WARNING "WARNING: " > > "I/O request space (%d reqs) < ring order %ld, " > > "consider increasing %s.reqs to >= %ld.", > > blkif_reqs, order, KBUILD_MODNAME, > > roundup_pow_of_two(BLK_RING_SIZE(order))); > > > > indicating that this _is_ a bottleneck), I'm otoh hesitant to convert > > this to per-instance allocations, as the amount of memory taken > > away from Dom0 for this may be not insignificant when there are > > many devices. > > > > Does anyone have an opinion here, in particular regarding the > > original authors' decision to make this global vs. the apparently > > made observation (by Daniel Stodden, the author of said patch, > > who I don't have any current email of to ask directly), but also > > in the context of multi-page rings, the purpose of which is to > > allow for larger amounts of in-flight I/O? > > Not really much to say other than we (well, mostly Wei Liu) have a > similar issue with netback too. That used to have a global pool, then a > pool-per-worker thread. When Wei added thread-per-vif support he solved > this by adding a "page pool" which handles allocations. Possibly this > could grow some sort of fairness etc nobs and be shared with blkback? Yes! That is what I was hoping for - as it would hopefully also have the shrinker API hooked up to combat excessive memory consumption. > > Ian. > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel