From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pat Campbell Subject: Re: Re: userspace block backend / gntdev problems Date: Fri, 25 Jan 2008 16:29:59 -0700 Message-ID: <479A70F7.7080405@novell.com> References: <477E3925.7070404@redhat.com> <1D19FC42-377A-47C7-8B6F-5BD56284C117@cl.cam.ac.uk> <87zluzowc7.fsf@pike.pond.sub.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <87zluzowc7.fsf@pike.pond.sub.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Markus Armbruster Cc: Derek Murray , Xen Development Mailing List , Gerd Hoffmann List-Id: xen-devel@lists.xenproject.org Markus Armbruster wrote: > Derek Murray writes: > > >> Hi Gerd, >> >> On 4 Jan 2008, at 13:48, Gerd Hoffmann wrote: >> >>> First problem is the fixed limit of 128 slots. The frontend >>> submits up >>> to 32 requests, with up to 11 grants each. With the shared ring this >>> sums up to 353 grants per block device. When is blkbackd running >>> in aio >>> mode, thus many requests are in flight at the same time and thus also >>> many grants mapped at the same time, the 128 limit is easily >>> reached. I >>> don't even need to stress the disk with bonnie or something, just >>> booting the virtual machine is enougth. Any chance replace the >>> fix-sized array with a list to remove that hard-coded limit? Or at >>> least raise the limit to -- say -- 1024 grants? >>> >> The 128-grant limit is fairly arbitrary, and I wanted to see how >> people were using gntdev before changing this. The reason for using a >> fixed-size array is that it gives us O(1)-time mapping and unmapping >> of single grants, which I anticipated would be the most frequently- >> used case. I'll prepare a patch that enables the configuration of >> this limit when the device is opened. >> > > Any news on this? I'd like to try converting the PV framebuffer to > use grants. I need to map ~2000-5000 pages, depending on the pvfb's > resolution. > > [...] > In my latest post on "Dynamic modes support for PV xenfb" I am using grants to map an extended framebuffer. I have a single grant ref that points to 10 other refs. The other refs contain MFNs. Same technique as the current framebuffer pd array but avoids the 64bit long issue. Kind of a hybrid approach. I am able to map a 22MB framebuffer when running a 64 bit guest and 44MB when running a 32 bit guest. When the backend is done with the mapping it sends a message to the frontend to free up the refs. I did try to map the whole framebuffers via grants, failed. Like you say you need a whole bunch of them.