[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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)

        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,

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?


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.