Re: [PATCH] xen: sched_credit: filter node-affinity mask against online cpus

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

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

On lun, 2013-09-16 at 16:27 +0100, George Dunlap wrote:
> On 16/09/13 16:23, Dario Faggioli wrote:
> > I tied to concentrate on the actual issue, which is avoid picking an
> > offline cpu, independently on which specific ASSERT is the one that
> > triggers.
> 
> Ok, but the question is, why AND it with online cpus here, but not in 
> the other place?  If the "actual issue" is that the mask may be empty, 
> it should be done in both places.  If the "actual issue" is that 
> cpu_cycle() chokes on empty masks, then that's an important think to 
> point out, so poor programmers don't get confused as to why it's 
> different. :-)
> 
It's a little bit of both. In fact, _csched_cpu_pick() *is* the only
function structure in such a way that the mask can't be empty (if we
leave node-affinity out). The other ones either don't care or account
for it in different ways and places, and that was like that even before
of my NUMA-aware scheduling patches... So, yes, that one call site is,
if not special, at least different from the other ones.

At the same time, you are right in saying that the consequence of the
above which is really bothering and calling for this fix _is_ indeed
that the ASSERT() fails.

So, I'm re-sending the patch with an updated comment which hopefully
clarifies the situation a bit more.

Let me know what you think about it (e-mail coming right after this one)

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