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] Re: blktap: Sync with XCP, dropping zero-copy.

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] Re: blktap: Sync with XCP, dropping zero-copy.
From: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Date: Mon, 15 Nov 2010 19:19:38 +0000
Cc: "Xen-devel@xxxxxxxxxxxxxxxxxxx" <Xen-devel@xxxxxxxxxxxxxxxxxxx>, Daniel Stodden <Daniel.Stodden@xxxxxxxxxx>
Delivery-date: Mon, 15 Nov 2010 11:20:37 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4CE17B80.7080606@xxxxxxxx>
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>
Organization: Citrix Systems, Inc.
References: <1289604707-13378-1-git-send-email-daniel.stodden@xxxxxxxxxx> <4CDDE0DA.2070303@xxxxxxxx> <1289620544.11102.373.camel@xxxxxxxxxxxxxxxxxxxxxxx> <4CE17B80.7080606@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Mon, 2010-11-15 at 18:27 +0000, Jeremy Fitzhardinge wrote:
> Then we'd have a set of frames whose lifetimes are being determined by
> some other subsystem.  We can either maintain a list of them and poll
> waiting for them to become free, or just release them and let them be
> managed by the normal kernel lifetime rules (which requires that the
> memory attached to them be completely normal, of course). 

GNTTABOP_unmap_and_replace is probably the answer to this? This is what
netback uses (via gnttab_copy_grant_page) when it wants to copy and skb
which has remained in flight for too long.

Maybe this doesn't work since the memcpy and replace are not atomic and
we don't have a lock to use, since we don't know which subsystem holds
the reference. However it should work if we don't really care about the
contents of the replacement too much, which I don't think we do in this
case since the data could just as easily get clobbered by the userspace
process which thinks the write has completed fully, in which case we
just replace the grant mapping without bothering with the copy.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>