All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Vrabel <david.vrabel@citrix.com>
To: andres@lagarcavilla.org
Cc: Andres Lagar-Cavilla <andres@gridcentric.ca>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel@lists.xen.org
Subject: Re: [PATCH] Xen backend support for paged out grant targets.
Date: Fri, 31 Aug 2012 15:32:10 +0100	[thread overview]
Message-ID: <5040CAEA.7000600@citrix.com> (raw)
In-Reply-To: <1346086287-17674-1-git-send-email-andres@lagarcavilla.org>

On 27/08/12 17:51, andres@lagarcavilla.org wrote:
> From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> Since Xen-4.2, hvm domains may have portions of their memory paged out. When a
> foreign domain (such as dom0) attempts to map these frames, the map will
> initially fail. The hypervisor returns a suitable errno, and kicks an
> asynchronous page-in operation carried out by a helper. The foreign domain is
> expected to retry the mapping operation until it eventually succeeds. The
> foreign domain is not put to sleep because itself could be the one running the
> pager assist (typical scenario for dom0).
> 
> This patch adds support for this mechanism for backend drivers using grant
> mapping and copying operations. Specifically, this covers the blkback and
> gntdev drivers (which map foregin grants), and the netback driver (which copies
> foreign grants).
> 
> * Add GNTST_eagain, already exposed by Xen, to the grant interface.
> * Add a retry method for grants that fail with GNTST_eagain (i.e. because the
>   target foregin frame is paged out).
> * Insert hooks with appropriate macro decorators in the aforementioned drivers.

I think you should implement wrappers around HYPERVISOR_grant_table_op()
have have the wrapper do the retries instead of every backend having to
check for EAGAIN and issue the retries itself. Similar to the
gnttab_map_grant_no_eagain() function you've already added.

Why do some operations not retry anyway?

> +void
> +gnttab_retry_eagain_gop(unsigned int cmd, void *gop, int16_t *status,
> +						const char *func)
> +{
> +	u8 delay = 1;
> +
> +	do {
> +		BUG_ON(HYPERVISOR_grant_table_op(cmd, gop, 1));
> +		if (*status == GNTST_eagain)
> +			msleep(delay++);
> +	} while ((*status == GNTST_eagain) && delay);

Terminating the loop when delay wraps is a bit subtle.  Why not make
delay unsigned and check delay <= MAX_DELAY?

Would it be sensible to ramp the delay faster?  Perhaps double each
iteration with a maximum possible delay of e.g., 256 ms.

> +#define gnttab_map_grant_no_eagain(_gop)                                    \
> +do {                                                                        \
> +    if ( HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, (_gop), 1))      \
> +        BUG();                                                              \
> +    if ((_gop)->status == GNTST_eagain)                                     \
> +        gnttab_retry_eagain_map((_gop));                                    \
> +} while(0)

Inline functions, please.

David

  reply	other threads:[~2012-08-31 14:32 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-27 16:51 [PATCH] Xen backend support for paged out grant targets andres
2012-08-31 14:32 ` David Vrabel [this message]
2012-08-31 14:45   ` Andres Lagar-Cavilla
2012-08-31 15:42     ` Andres Lagar-Cavilla
2012-08-31 16:10       ` David Vrabel
2012-09-05 16:27         ` Konrad Rzeszutek Wilk
2012-09-05 17:21           ` Andres Lagar-Cavilla
2012-09-12 13:20             ` Andres Lagar-Cavilla
2012-09-12 18:30               ` Konrad Rzeszutek Wilk
2012-08-31 16:54       ` Konrad Rzeszutek Wilk
2012-08-31 19:33         ` Andres Lagar-Cavilla
2012-08-31 21:14           ` Konrad Rzeszutek Wilk
2012-09-12 19:50 Andres Lagar-Cavilla
     [not found] <1347479153-441-1-git-send-email-andres@lagarcavilla.org>
2012-09-12 20:06 ` Konrad Rzeszutek Wilk
2012-09-12 20:21   ` Andres Lagar-Cavilla
2012-09-13  0:04     ` Andres Lagar-Cavilla
     [not found] ` <1347520482.25803.46.camel@dagon.hellion.org.uk>
2012-09-13 14:24   ` Andres Lagar-Cavilla
2012-09-13 17:28 Andres Lagar-Cavilla
2012-09-13 18:11 ` Ian Campbell
2012-09-13 19:45   ` Andres Lagar-Cavilla
2012-09-14  7:19     ` Ian Campbell
2012-09-14 12:44       ` Konrad Rzeszutek Wilk
2012-09-14 14:27         ` Andres Lagar-Cavilla

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=5040CAEA.7000600@citrix.com \
    --to=david.vrabel@citrix.com \
    --cc=andres@gridcentric.ca \
    --cc=andres@lagarcavilla.org \
    --cc=konrad.wilk@oracle.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.