Re: [PATCH] xen: add hypercall option to temporarily pin a vcpu

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2880 bytes --]

On Fri, 2016-02-26 at 05:39 -0700, Jan Beulich wrote:
> > 
> > > > On 26.02.16 at 12:20, <dario.faggioli@citrix.com> wrote:
> > On Fri, 2016-02-26 at 12:14 +0100, Juergen Gross wrote:
> > > 
> > > EBUSY vs. EAGAIN: by returning EAGAIN I would signal to Xen tools
> > > that
> > > the hypervisor is currently not able to do the desired operation
> > > (especially removing a cpu from a cpupool), but the situation
> > > will
> > > change automatically via scheduling. EBUSY will stop retries in
> > > Xen
> > > tools and this is want I want here: I can't be sure the situation
> > > will change soon.
> > > 
> > I agree with this.
> I'm of two minds here: I can see your viewpoint, but considering
> this is called "temporarily pin a vcpu" the condition is supposed to
> be going away again soon.
> 
Maybe one difference is that it won't go away "by itself". I.e., just
retrying in a while, especially if from inside Xen, and without anyone
explicitly calling the hypercall again with proper argument, nothing
will change.

> > > > Wouldn't it be even better to make this the "else" to the
> > > > preceding if(), since in the suspend case this is otherwise
> > > > going
> > > > to be printed for every vCPU not currently running on pCPU0?
> > > Yes, I'll change it.
> > > 
> > On this, can (either of) you elaborate a bit more? I don't think
> > I'm
> > following...
> In addition to Jürgen's reply: My main concern here is that on
> a bug system this message would get printed for almost every
> vCPU in the system, which could end up being a lot of noise.
> 
> And there's a similar message on the resume side I think -
> perhaps that one should be silenced too.
> 
What I don't understand is this part of your first comment "in the
suspend case this is otherwise going to be printed for every vCPU not
currently running on pCPU0".

First, do you mean with Juergen's patch, or even right now?

And anyway, this is going to be printed for all the vCPUs that does not
have, in their hard affinity, any of the pCPUs that are going to remain
online (or to remain in the domain's cpupool).

In shutdown and suspend, when we try to move everything to pCPU 0, it
will get printed for all the vCPUs that does not have pCPU 0 in their
hard affinity.

We can argue about that being useful or not, and about it being
(potentially) too noisy or not. I personally think it could be useful
(it's XENLOG_DEBUG, after all), but I won't oppose getting rid of it...
I am just not getting why you're saying "not currently running on
pCPU0".

Thanks and Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel