Re: [PATCH 1/2] sched: credit2: respect per-vcpu hard affinity

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

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

On Sat, 2015-01-31 at 20:51 -1000, Justin Weaver wrote:
> On Mon, Jan 19, 2015 at 9:21 PM, Justin Weaver <jtweaver@hawaii.edu> wrote:

> > Like I said above, I will look at this again. My VMs were getting
> > stuck after certain hard affinity changes. I'll roll back some of
> > these changes and test it out again.
> 
> I discovered that SCHED_OP(VCPU2OP(v), wake, v); in function vcpu_wake
> in schedule.c is not being called because v's pause flags has
> _VPF_blocked set.
> 
> For example...
> I start a guest with one vcpu with hard affinity 8 - 15 and xl
> vcpu-list says it's running on pcpu 15
> I run xl vcpu-pin 1 0 8 to change it to hard affinity only with pcpu 8
> When it gets to vcpu_wake, it tests vcpu_runnable(v) which is false
> because _VPF_blocked is set, so it skips the call to
> SCHED_OP(VCPU2OP(v), wake, v); and so does not get a runq_tickle
> xl vcpu-list now shows --- for the state and I cannot console into it
> What I don't understand though is if I then enter xl vcpu-pin 1 0 15
> it reports that _VPF_blocked is NOT set, vcpu_wake calls credit2's
> wake, it gets a runq_tickle and everything is fine again
> Why did the value of the _VPF_blocked flag change after I entered xl
> vcpu-pin the second time?? I dove deep in the code and could not
> figure it out.
> 
> So that is why v1 of my patch worked because I let it run migrate
> during an affinity change even if the current and destination run
> queues were the same, so it would do the processor assignment and
> runq_tickle regardless. I think you'll have to tell me if that's a
> hack or a good solution!
> 
Ok, thanks for the analysis. I shall have a look and let you know.

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