Re: [Xen-devel] [PATCH] xen: avoid updating node affinity twice when removing a CPU from a cpupool

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Thu, 2015-03-12 at 14:51 +0000, Jan Beulich wrote:
> >>> On 12.03.15 at 14:45, <dario.faggioli@xxxxxxxxxx> wrote:
> > Patch below, and attached. However, I think the correct thing to do
> > would be to just revert 93be8285 "update domU's node-affinity on the
> > cpupool_unassign_cpu() path", wouldn't it?
> 
> Indeed - if the presented patch is what we want, it should be
> carried out as a revert. But you'll then want to explain why you
> did what you did there in the first place: 
>
Because I thought it was necessary. ISTR I spotted the lack of symmetry
that George is also mentioning, by looking at its _assign_ counterpart,
and did not notice, at that time, that it was actually ok, as the update
happens already, although in schedule.c...

> It surely wasn't without
> reason, 
>
It was for a wrong reason. :-)

> and hence I'd be afraid the revert would re-introduce
> another problem. That explanation should then probably go in
> as description for the revert.
> 
I'm not sure I'm getting 100% of what you mean. Let me try:

<<Change 93be8285 ("update domU's node-affinity on the
cpupool_unassign_cpu() path") is wrong. In fact, as a consequence of it,
domains' node affinity is updated twice when a pCPU is removed from a
cpupool. It seemed necessary to add such call in cpupool_unassign_cpu(),
for symmetry with its _assign_ counterpart, but it went unnoticed that
the update was already being performed, in cpu_disable_scheduler().

Besides being conceptually wrong, it causes issues, in the form of an
ASSERT() that triggers, in debug builds.

For these reasons, 93be8285 really needs to be undone.>>

Was it something like this you were after? If not, please advise
further... And sorry for the whole thing! :-/

Regards,
Dario

Attachment: signature.asc
Description: This is a digitally signed message part

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