[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] blkfront failure on migrate
>>> On 22.11.12 at 16:07, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote: > On 22/11/12 13:46, Jan Beulich wrote: >>>>> On 22.11.12 at 13:57, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote: >>> In "Stage 1" as commented, we make a copy of the shadow map. We then >>> reset the contents of the real shadow map, and selectively copy the >>> in-use entries back from the copy to the real map. >>> >>> Looking at the code, it appears possible to do this rearranging inplace >>> in the real shadow map, without requiring any memory allocation. >>> >>> Is this a sensible suggestion or have I overlooked something? This >>> order-5 allocation is a disaster lying in wait for VMs with high memory >>> pressure. >> While merging the multi-page ring patches, I think I tried to make >> this an in place copy operation, and it didn't work (don't recall >> details though). This and/or the need to deal with shrinking ring >> size across migration (maybe that was what really didn't work) >> made me move stage 3 to kick_pending_request_queues(), and >> allocate entries that actually need copying one by one, sticking >> them on a list. > > Where are your multi-page ring patches? Are you saying this code is > going to change very shortly? Oh, I implied that this was for our (forward ported) kernel (which can be found at http://kernel.opensuse.org/git, and the master and SLE11-SP3 branches should have those patches). > If the copy and copy back really cant be avoided, then making > "sizeof(info->shadow)/PAGE_SIZE" allocations of order 0 would be > substantially more friendly to environments with high memory pressure, > at the cost of slightly more complicated indexing in the loop. As I said, I converted the one big allocation into per-entry ones (at once avoiding to allocate space for entries that aren't in use). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |