Re: xen-blkfront: simplify resume?

[Shriram Rajagopalan <rshriram@cs.ubc.ca>]

[-- Attachment #1.1: Type: text/plain, Size: 1637 bytes --]

On Thu, Mar 24, 2011 at 2:31 AM, Daniel Stodden
<daniel.stodden@citrix.com>wrote:

>
> Dear xen-devel.
>
> I think the blkif_recover (blkfront's transparent VM resume) stuff looks
> quite overcomplicated.
>
> We copy the ring message to a shadow request allocated during submit, a
> process involving some none-obvious-looking get_id_from_freelist()
> subroutine to obtain a vector slot, and a memcpy.
>
> When receiving a resume callback from xenstore, we memcpy the entire
> shadow vector, reset the original one to zero, then reallocate the
> thereby freed shadow entries and not only copy the message on the ring,
> but the shadow back into the shadow vector just freed to keep stuff
> consistent. Hmmm.
>
> I wonder, should we just take the pending request and push it back onto
> the request_queue (with a blk_requeue_request)?
>
> Different from the present code, this should also help preserve original
> submit order if done right. (Don't panic, not like it matters a lot
> anymore since the block barrier flags are gone.)
>
> If we want to keep the shadow copy, let's do so with a prep_rq_fn. It
> gets called before the request gets pulled off the queue. Looks nicer,
> and one can arrange things so it only gets called once.
>
> Counter opinions?
>
> A bit confused. If things were as simple as stuffing the pending reqs back
into the req_queue, why resort to shadowing the requests in the first place?
(esp, with the blk barrier flags gone)

shriram

> Thanks,
> Daniel
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

[-- Attachment #1.2: Type: text/html, Size: 2323 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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