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/
Home Products Support Community News


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)


Xen-devel mailing list

Xen-devel mailing list
<Prev in Thread] Current Thread [Next in Thread>