Re: [Xen-devel] Insane contiguous physical memory requirements in blkbk/blktap

["Stephen C. Tweedie" <sct@xxxxxxxxxx>]

Hi,

On Thu, 2006-10-05 at 16:47 +0100, Keir Fraser wrote:

> > I've been looking at the exact same question, but don't know the
> > answer.  If you come up with a patch before I do, I'd be thrilled to
> > test it.
> 
> This is easily fixable. Anywhere we use the virtual address to compute an
> offset into a state structure, we can instead store the appropriate 'slot
> index' in a spare field in the appropriate 'struct page'.

As far as I can tell, nothing uses the VA in any way --- it can't,
because the start of the order-10 kmalloc area is not actually used
anywhere after the initial mmap setup.  After making the variable
mmap_vstart local to the __init function, everything still compiles, so
I don't think there's anything lurking in header files that implicitly
relies on it.

There is a

                ret = HYPERVISOR_memory_op(XENMEM_decrease_reservation,
                                           &reservation);

call on the entire range, though, if (xen_feature
(XENFEAT_auto_translated_physmap)) is true.  Those reservations are one-
off requests, aren't they?  I don't think we're adding overhead by doing
this for 1024 separate pages rather than a single order-10 chunk, but
I'd appreciate a second opinion there.

> That really only leaves the question of how much of this can be put in a
> helper function (probably in balloon driver again) for use of all our
> drivers.

Right --- a helper which returns a vm-detached page vector rather than a
vaddr is exactly what I had in mind.

--Stephen



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel