From: David Vrabel <david.vrabel@citrix.com>
To: Zoltan Kiss <zoltan.kiss@huawei.com>,
"Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>
Subject: Re: Linux grant map/unmap improvement proposal (Draft B)
Date: Thu, 16 Oct 2014 16:54:36 +0100 [thread overview]
Message-ID: <543FEA3C.2070207@citrix.com> (raw)
In-Reply-To: <543EB2A2.7040005@huawei.com>
On 15/10/14 18:45, Zoltan Kiss 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.
> I'm a bit confused about this function. I guess it checks the refcount
> before unmap. But then what does the done(data) function does?
It's needed to callback into the calling driver once the unmap is
eventually complete, so it can complete the request etc.
>> 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.
>
> Who will own this queue? The caller (e.g. blkback)? How often should it
> retry? That retry is triggered by a timer?
It will be common and managed the core grant table subsystem/module.
The retry will be a simple timer. This is expected to be such a rare
event that anything more sophisticated isn't necessary.
>> Identifying foreign pages
>> -------------------------
>>
>> A new page flag is introduced: PG_foreign. This will alias PG_pinned
>> so it does not require an additional bit.
>>
>> If PG_foreign is set then `page->private` contains the grant reference
>> and domid for this foreign page. This information can only be packed
>> into an unsigned long on 64-bit platforms. 32-bit platforms will have
>> to allocate an additional structure to store the domid and gref.
>>
>> The aliasing of PG_foreign and PG_pinned is safe because:
>>
>> - Page table pages will never be foreign.
>> - Foreign pages shall have `p2m[P] & FOREIGN_FRAME_BIT`.
>>
>> The use of the private field is safe because:
>>
>> - The page is allocated by the balloon driver and thus it owns the
>> private field.
>>
>> - The other fields in the union (ptl, slab_cache, and first_page) will
>> not be used because the page is not used in a page table, slab or
>> compound page.
>>
> This flag sounds similar to the flag used in classic for netback grant
> mapping. Would it be accepted in upstream? Aliasing PG_pinned would make
> sure of that?
This should be the case.
David
next prev parent reply other threads:[~2014-10-16 15:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-13 13:41 Linux grant map/unmap improvement proposal (Draft B) David Vrabel
2014-10-13 16:43 ` Stefano Stabellini
2014-10-13 17:22 ` David Vrabel
2014-10-14 10:27 ` Ian Campbell
2014-10-14 10:32 ` David Vrabel
2014-10-14 10:35 ` Ian Campbell
2014-10-14 12:49 ` David Vrabel
2014-10-14 12:59 ` Ian Campbell
2014-10-15 17:45 ` Zoltan Kiss
2014-10-16 15:54 ` David Vrabel [this message]
2014-12-18 17:55 ` David Vrabel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=543FEA3C.2070207@citrix.com \
--to=david.vrabel@citrix.com \
--cc=Xen-devel@lists.xen.org \
--cc=zoltan.kiss@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.