From: Juergen Gross <jgross@suse.com>
To: Dario Faggioli <dario.faggioli@citrix.com>,
George Dunlap <george.dunlap@citrix.com>,
xen-devel@lists.xen.org
Cc: wei.liu2@citrix.com, stefano.stabellini@eu.citrix.com,
george.dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
ian.jackson@eu.citrix.com, david.vrabel@citrix.com,
jbeulich@suse.com
Subject: Re: [PATCH v2 2/3] xen: add hypercall option to temporarily pin a vcpu
Date: Wed, 2 Mar 2016 18:15:08 +0100 [thread overview]
Message-ID: <56D71F9C.3060208@suse.com> (raw)
In-Reply-To: <1456934611.2959.371.camel@citrix.com>
On 02/03/16 17:03, Dario Faggioli wrote:
> On Wed, 2016-03-02 at 16:34 +0100, Juergen Gross wrote:
>> On 02/03/16 10:27, Dario Faggioli wrote:
>>>
>>> However, an xl flag is easier to add, easier to document and easier
>>> and
>>> more natural to find, from the point of view of an user that really
>>> needs it. And perhaps it could turn out useful for other situations
>>> in
>>> future. So, I guess I'd say:
>>> - yes, let's add that
>>> - let's do it as a "force flag" of `xl vcpu-pin'.
>> Which raises the question: how to do that on the libxl level?
>>
> Ah, right.
>
>> a) expand libxl_set_vcpuaffinity() with another parameter (is this
>> even
>> possible? I could do some ifdeffery, but the API would change...)
>>
>> b) add a libxl_set_vcpuaffinity_force() variant
>>
>> c) imply the force flag by specifying both hard and soft maps as NULL
>> (it _is_ basically just that: keep both affinity sets), implying
>> that
>> it makes no sense to specify any affinities with the -f flag
>> (which
>> renders the "force" meaning rather strange, would be more a
>> "restore"
>> now).
>>
> Eheh, tools' maintainers' call. My preference would be b).
>
> I don't like a), mostly because that would mean everyone will need to
> specify a parameter that it is really only necessary in special cases.
>
> I could live with c), but it indeed makes the semantic too convoluted
> for my taste.
>
> I guess, however, that even if going for b), we need to decide whether
> to require a cpumask or not, and what to do if one passes NULL. Maybe
> we can have a cpumask parameter and,
> - if it is not NULL, force affinity to that,
> - if it is NULL, just 'restore';
> what do you think?
I would just let the force flag restore the old setting (thus clearing
the affinity_broken flag) and then apply the normal affinity settings.
> Actually, at Xen level, the override only acts on hard affinity...
> should libxl take only one cpumask (for hard affinity only), or both
> hard and soft?
Just as the user is specifying: 0, 1 or 2.
> I'd say just one for hard is enough, unless we want to make space for a
> potential future situation where we will want to break and restore soft
> affinity as well...
The force flag would be just an add-on. That's rather easy in the
hypervisor and in the tools.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-03-02 17:15 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-01 9:02 [PATCH v2 0/3] add hypercall option to temporarily pin a vcpu Juergen Gross
2016-03-01 9:02 ` [PATCH v2 1/3] xen: silence affinity messages on suspend/resume Juergen Gross
2016-03-02 11:11 ` Dario Faggioli
2016-03-01 9:02 ` [PATCH v2 2/3] xen: add hypercall option to temporarily pin a vcpu Juergen Gross
2016-03-01 11:27 ` Jan Beulich
2016-03-01 11:55 ` David Vrabel
2016-03-01 11:58 ` Juergen Gross
2016-03-01 12:15 ` Dario Faggioli
2016-03-01 14:02 ` George Dunlap
[not found] ` <56D58ABF02000078000D7C46@suse.com>
2016-03-01 11:58 ` Juergen Gross
2016-03-01 15:52 ` George Dunlap
2016-03-01 15:55 ` George Dunlap
2016-03-01 16:11 ` Jan Beulich
2016-03-02 7:14 ` Juergen Gross
2016-03-02 9:27 ` Dario Faggioli
2016-03-02 11:19 ` Juergen Gross
2016-03-02 11:49 ` Dario Faggioli
2016-03-02 12:12 ` Juergen Gross
2016-03-02 15:34 ` Juergen Gross
2016-03-02 16:03 ` Dario Faggioli
2016-03-02 17:15 ` Juergen Gross [this message]
2016-03-02 17:21 ` Anshul Makkar
2016-03-03 5:31 ` Juergen Gross
2016-03-01 9:02 ` [PATCH v2 3/3] libxc: do some retries in xc_cpupool_removecpu() for EBUSY case Juergen Gross
2016-03-01 11:58 ` Wei Liu
2016-03-01 11:59 ` Juergen Gross
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=56D71F9C.3060208@suse.com \
--to=jgross@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=dario.faggioli@citrix.com \
--cc=david.vrabel@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=george.dunlap@eu.citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=jbeulich@suse.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=wei.liu2@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).