Re: [PATCH 03 of 10 v2] xen: sched_credit: let the scheduler know about node-affinity

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

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

On Fri, 2012-12-21 at 14:56 +0000, George Dunlap wrote: 
> > I hope I've explained it correctly, and sorry if it is a little bit
> > tricky, especially to explain like this (although, believe me, it was
> > tricky to hunt it out too! :-P). I've seen that happening and I'm almost
> > sure I kept a trace somewhere, so let me know if you want to see the
> > "smoking gun". :-)
> 
> No, the change looks quite plausible.  I guess it's not obvious that the 
> balancing code will never migrate from one thread to another thread.  
>
It was far from obvious to figure out this was happening, yes. :-)

> (That whole algorithm could do with some commenting -- I may submit a 
> patch once this series is in.)
> 
Nice.

> I'm really glad you've had the opportunity to take a close look at these 
> kinds of things.
>
Yeah, well, I'm happy to, scheduling never stops entertaining me, even
(or especially) when it requires my brain-cells to workout so hard! :-D

> What I was doing, 
> in a sort of "thinking out loud" fashion, seeing under what conditions 
> that break might actually happen.  Like the analysis with 
> vcpu_should_migrate(), it might have turned out to be redundant, or to 
> have missed some cases.
>
Yep, I agree, it's another aspects of the patch-review model which is
really helpful.

Thanks,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/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: 198 bytes --]

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

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