From: Pat Campbell <plc@novell.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: Derek Murray <Derek.Murray@cl.cam.ac.uk>,
Xen Development Mailing List <xen-devel@lists.xensource.com>,
Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: Re: userspace block backend / gntdev problems
Date: Fri, 25 Jan 2008 16:29:59 -0700 [thread overview]
Message-ID: <479A70F7.7080405@novell.com> (raw)
In-Reply-To: <87zluzowc7.fsf@pike.pond.sub.org>
Markus Armbruster wrote:
> Derek Murray <Derek.Murray@cl.cam.ac.uk> 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.
next prev parent reply other threads:[~2008-01-25 23:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-04 13:48 userspace block backend / gntdev problems Gerd Hoffmann
2008-01-04 14:50 ` Derek Murray
2008-01-04 15:24 ` Gerd Hoffmann
2008-01-21 18:41 ` Markus Armbruster
2008-01-25 23:29 ` Pat Campbell [this message]
2008-01-26 8:41 ` Markus Armbruster
2008-01-26 8:48 ` Keir Fraser
2008-01-28 0:40 ` Pat Campbell
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=479A70F7.7080405@novell.com \
--to=plc@novell.com \
--cc=Derek.Murray@cl.cam.ac.uk \
--cc=armbru@redhat.com \
--cc=kraxel@redhat.com \
--cc=xen-devel@lists.xensource.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.