From: David Vrabel <david.vrabel@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: <xen-devel@lists.xen.org>, <linux-kernel@vger.kernel.org>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [PATCH v3] p2m: use GNTTABOP_unmap_and_duplicate if available
Date: Tue, 5 Nov 2013 10:47:32 +0000 [thread overview]
Message-ID: <5278CCC4.3020501@citrix.com> (raw)
In-Reply-To: <1383579524-12465-1-git-send-email-roger.pau@citrix.com>
On 04/11/13 15:38, Roger Pau Monne wrote:
> The new GNTTABOP_unmap_and_duplicate operation doesn't zero the
> mapping passed in new_addr, allowing us to perform batch unmaps in p2m
> code without requiring the use of a multicall.
Should the grant maps should be batched in a similar way?
> +int m2p_remove_override_batch(struct page **pages,
> + struct gnttab_map_grant_ref *kmap_ops, int count)
> +{
> + struct gnttab_unmap_and_duplicate *unmap_ops = NULL;
> + int ret = 0, i;
> +
> + for (i = 0; i < count; i++) {
> + ret = remove_page_override(pages[i]);
> + if (ret)
> + goto out;
> + }
> +
> + if (kmap_ops != NULL) {
> + struct page *scratch_page = get_balloon_scratch_page();
> + unsigned long scratch_page_address = (unsigned long)
> + __va(page_to_pfn(scratch_page) << PAGE_SHIFT);
> + int invcount = 0;
> +
> + unmap_ops = kcalloc(count, sizeof(unmap_ops[0]), GFP_KERNEL);
> + if (!unmap_ops) {
> + put_balloon_scratch_page();
> + ret = -ENOMEM;
> + goto out;
> + }
A memory allocation failure here looks bad as the grants will not be
unmapped which will have an impact on the granter domain. Either: a)
the unmap ops should be constructed in advance (excluding high mem pages
at that point); or b) this should use a statically allocated per-cpu
array of unmap ops with the batch split as necessary to fit into the
static array.
David
next prev parent reply other threads:[~2013-11-05 10:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-04 15:38 [PATCH v3] p2m: use GNTTABOP_unmap_and_duplicate if available Roger Pau Monne
2013-11-04 15:49 ` Ian Campbell
2013-11-04 15:49 ` [Xen-devel] " Ian Campbell
2013-11-04 16:09 ` Roger Pau Monné
2013-11-04 16:09 ` [Xen-devel] " Roger Pau Monné
2013-11-04 16:26 ` Ian Campbell
2013-11-04 16:26 ` [Xen-devel] " Ian Campbell
2013-11-05 10:47 ` David Vrabel
2013-11-05 10:47 ` David Vrabel [this message]
2013-11-07 11:12 ` David Vrabel
2013-11-07 11:12 ` David Vrabel
-- strict thread matches above, loose matches on Subject: below --
2013-11-04 15:38 Roger Pau Monne
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=5278CCC4.3020501@citrix.com \
--to=david.vrabel@citrix.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=roger.pau@citrix.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xen.org \
/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.