WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] xen-blkfront: simplify resume?

To: Daniel Stodden <daniel.stodden@xxxxxxxxxx>
Subject: Re: [Xen-devel] xen-blkfront: simplify resume?
From: Shriram Rajagopalan <rshriram@xxxxxxxxx>
Date: Thu, 24 Mar 2011 13:08:42 -0700
Cc: Xen Developers <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 24 Mar 2011 13:10:21 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1300959061.3507.1600.camel@xxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1300959061.3507.1600.camel@xxxxxxxxxxxxxxxx>
Reply-to: rshriram@xxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Thu, Mar 24, 2011 at 2:31 AM, Daniel Stodden <daniel.stodden@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>