[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Linux grant map/unmap improvement proposal (Draft B)



On 14/10/14 11:27, Ian Campbell wrote:
> On Mon, 2014-10-13 at 14:41 +0100, David Vrabel wrote:
>> Safe grant unmap
>> ----------------
>>
>> Grant references will only be unmapped when they are no longer in use.
>> i.e., the page reference count is one.
>>
>>     int gnttab_unmap_refs_async(struct gnttab_unmap_grant_ref *unmap_ops,
>>         struct gnttab_unmap_grant_ref *kunmap_ops,
>>         struct page **pages, unsigned int count,
>>         void (*done)(void *data), void *data);
>>
>> The `gnttab_unmap_refs_async()` function will unmap the grant
>> references using the supplied unmap operations and call `done(data)`.
>> The grant unmap will only be done once all pages are no longer in use.
>>
>> It shall run synchronously on the first attempt (this is expected to
>> be the most common case).  If any page is in use, it shall queue the
>> unmap request to be tried at a later time.
>>
>> Only the blkback and gntdev devices need to use asynchronouse unmaps.
> 
> What about storage over networking? Does this work for that case too? I
> suppose that would just manifest as >1 reference counts when the blk op
> finishes, which would be taken care of by the delay.

I'm not sure I follow what use case you're talking about here.  If the
guest is using NFS or iSCSI or similar, then netback just sees ethernet
packets and doesn't need to distinguish between different types of
network traffic from the guest.

David

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.