Re: [Xen-devel] blkfront failure on migrate

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel