From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jens Axboe Subject: Re: [GIT PULL] (xen) stable/for-jens-3.8 Date: Mon, 12 Nov 2012 09:19:14 -0700 Message-ID: <50A12182.90305@kernel.dk> References: <20121109145529.GB23023@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20121109145529.GB23023@phenom.dumpdata.com> Sender: linux-kernel-owner@vger.kernel.org To: Konrad Rzeszutek Wilk Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 2012-11-09 07:55, Konrad Rzeszutek Wilk wrote: > Hey Jens, > > Please git pull the following branch: > > git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-jens-3.8 > > which has a new feature of the blk[back|front] driver - it is called 'feature-persistent'. > Roger and Oliver patch says: > " This patch implements persistent grants for the xen-blk{front,back} > mechanism. The effect of this change is to reduce the number of unmap > operations performed, since they cause a (costly) TLB shootdown. This > allows the I/O performance to scale better when a large number of VMs > are performing I/O. > > Previously, the blkfront driver was supplied a bvec[] from the request > queue. This was granted to dom0; dom0 performed the I/O and wrote > directly into the grant-mapped memory and unmapped it; blkfront then > removed foreign access for that grant. The cost of unmapping scales > badly with the number of CPUs in Dom0. An experiment showed that when > Dom0 has 24 VCPUs, and guests are performing parallel I/O to a > ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests > (at which point 650,000 IOPS are being performed in total). If more > than 5 guests are used, the performance declines. By 10 guests, only > 400,000 IOPS are being performed. > > This patch improves performance by only unmapping when the connection > between blkfront and back is broken. > " > > Note: You might get a conflict in the common.h file. It should > be fairly easy to fix it - it should end up looking as this: > > 160 /* Cached size parameter. */ > 161 sector_t size; > 162 unsigned int flush_support:1; > 163 unsigned int discard_secure:1; > 164 unsigned int feature_gnt_persistent:1; > 165 unsigned int overflow_max_grants:1; > 166 }; > > Thanks! Thanks, pulled. No conflict observed, it merged cleanly. -- Jens Axboe