All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 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.