WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] [PATCH] CPU affinity reset during save/restore

To: Jiri Denemark <jdenemar@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xen-devel] [PATCH] CPU affinity reset during save/restore
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Thu, 13 Nov 2008 15:14:21 +0000 (GMT)
Cc:
Delivery-date: Thu, 13 Nov 2008 07:15:32 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20081113084027.GA18897@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
I looked at this problem a few months ago.  Your solution
looks great for save/restore on the same machine.  But if
the restore occurs on another machine that doesn't have
the same set of CPUs, does the right thing happen?  (And
more importantly, what is "the right thing" for a very
different set of CPUs, for example saving on a machine
with no hyperthreading and restoring on one with hyper-
threading?)

Even on the same machine, affinity decisions for domain X
that are made between save of domain Y and restore of
domain Y might imply that the same affinities for domain
Y should not be applied on restore of Y.

So after thinking about it, I decided not to implement
this as IMHO affinity decisions are best left to higher
level management tools.
 

> -----Original Message-----
> From: Jiri Denemark [mailto:jdenemar@xxxxxxxxxx]
> Sent: Thursday, November 13, 2008 1:40 AM
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-devel] [PATCH] CPU affinity reset during save/restore
> 
> 
> Hi,
> 
> This is the same patch I sent earlier this week with 
> Signed-off-by-line added.
> 
> Even though there is a quite old cs 14588
> (http://xenbits.xensource.com/xen-unstable.hg?rev/853853686147
) described as a
fix to this issue, the CPU affinity is still reset after dom-U being saved and
restored in current xen-unstable.

I found two reasons for this. First, although XendConfig._parse_sxp() tries to
parse the affinity from 'cpus', the list is not stored in domain's checkpoint
file. This is because cs 15152
(http://xenbits.xensource.com/xen-unstable.hg?rev/681ed46676a6) prevents
'cpus' list to be generated in XendConfig.to_sxp().

Second, even though 'cpus' is correctly parsed in XendConfig._parse_sxp(), it
is not used for setting CPU affinity in XendDomainInfo.resume().

That said, after reverting cs 14588 and applying the attached patch, the CPU
affinity is correctly restored after restoring the domain.

The attached patch just copies the code related to CPU affinity from
XendDomainInfo._initDomain() into XendDomainInfo._setCPUAffinity() and calls
this method from _initDomain() and resume().

What do you think about this way to fix the CPU affinity reset? If it is not
the right way, what way do you prefer this issue to be fixed?

Any comments how the patch could be improved are most welcome.

Signed-off-by: Jiri Denemark <jdenemar@xxxxxxxxxx>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>