From: Jan Beulich <jbeulich@suse.com>
To: "Durrant, Paul" <pdurrant@amazon.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] max_grant_frames/max_maptrack_frames
Date: Fri, 8 Nov 2019 12:38:05 +0100 [thread overview]
Message-ID: <86d72e83-abf6-bef3-418f-49a69545fcb5@suse.com> (raw)
In-Reply-To: <f9e3fb8cadf44352851d865e850c6525@EX13D32EUC003.ant.amazon.com>
On 08.11.2019 09:45, Durrant, Paul wrote:
> When per-domain options for maximum grant and maptrack frames came in (in 4.10?) Xen's behaviour w.r.t. to the global command line values (gnttab_max_frames and gnttab_max_maptrack_frames respectively) regressed
>
> For example, a host running a prior version of Xen with a command line setting gnttab_max_frames=128 would have all of its domUs running with 128 frames. However, after update to a newer Xen, they will only get 32 frames (unless the host is particularly large, in which case they will get 64). Why is this? It's because neither xl.cfg files, nor xl.conf, will specify values (because the scenario is an update from an older installation) and so the hardcoded 32/64 default applies. Hence some domUs with large numbers of PV devices start failing (or at least substantially slow down) and admins start wondering what's going on.
>
> So how best to fix this?
>
> For the sake of a quick fix for the regression, and ease of back-porting, I think it would be best to add a check in domain_create() and create the grant table with parameters which are the larger of the toolstack configured value and the corresponding command line value.
How about people simply setting the value in xl.conf, if indeed in can be
set there?
> This does, however, go against the recent direction of the toolstack getting exactly what it asked for. So for the longer term I am wondering whether there ought to be a way for the toolstack to query the globally configured grant table limits. A GNTTABOP seems the wrong candidate for this, since GNTTABOPs are per-domain, so I'm wondering about a new sysctl to return the value of a named command line parameter.
Such a series was already posted (and even had some review, so it's
already at v4, but iirc no update has been provided since May):
https://lists.xenproject.org/archives/html/xen-devel/2019-05/msg02206.html
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2019-11-08 11:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-08 8:45 [Xen-devel] max_grant_frames/max_maptrack_frames Durrant, Paul
2019-11-08 11:38 ` Jan Beulich [this message]
2019-11-08 12:14 ` Jürgen Groß
2019-11-08 12:33 ` Durrant, Paul
2019-11-08 12:33 ` Durrant, Paul
2019-11-08 13:42 ` Jan Beulich
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=86d72e83-abf6-bef3-418f-49a69545fcb5@suse.com \
--to=jbeulich@suse.com \
--cc=pdurrant@amazon.com \
--cc=xen-devel@lists.xenproject.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.