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

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

Hi all,

blkbk and blktap do not load reliably as modules.  As soon as you hit a
boot where a fs needs to be fscked, memory gets fragmented, and the
order-10 (yes, *TEN*) kmalloc in balloon_alloc_empty_page_range() fails.

But is there any need at all for these pages to be contiguous?  All we
do with the start of the array is:

        for (i = 0; i < mmap_pages; i++) {
                pending_vaddrs[i] = mmap_vstart + (i << PAGE_SHIFT);
                pending_grant_handles[i] = BLKBACK_INVALID_HANDLE;
        }

and thereafter we only ever look at individual page addresses indexed
through pending_vaddrs[].

Given that we had problems recently with block IO failing when
straddling a page boundary, we certainly don't have any requirements for
contiguity during normal operations.  The only thing I can see is

struct page *balloon_alloc_empty_page_range(unsigned long nr_pages)
{
...

        balloon_lock(flags);
        if (xen_feature(XENFEAT_auto_translated_physmap)) {
                unsigned long gmfn = __pa(vstart) >> PAGE_SHIFT;
...
                set_xen_guest_handle(reservation.extent_start, &gmfn);
                ret = HYPERVISOR_memory_op(XENMEM_decrease_reservation,
                                           &reservation);

which is performing reservations on the whole extent.  Would there be
any real problem simply falling back to multiple reservations of lower
orders if we fail these calls?

--Stephen



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