From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Ray Bryant" Subject: Re: [XENOPROFILE] and "xm vcpu-pin" doesn't work as expected Date: Fri, 19 Jan 2007 15:06:49 -0600 Message-ID: <200701191506.49755.raybry@mpdtxmail.amd.com> References: <200612151721.10034.raybry@mpdtxmail.amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200612151721.10034.raybry@mpdtxmail.amd.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jose Renato G Cc: Thomas Friebel , xen-devel@lists.xensource.com, "Woller, Thomas" List-Id: xen-devel@lists.xenproject.org Renato, I've been trying to profile an HVM guest and its corresponding Xen usage so I used the "xm vcpu-pin" command to pin the HVM guest to CPU 1 and dom0 to CPU 0 (this is a single socket, dual core setup, but that probably doesn't matter here). I then used the opsetup --separate=cpu option to split out the profile samples by CPU, fully expecting to see no "domain1-xen" samples on CPU 0. However, what I actually see is 90% (more or less) of the samples on CPU 0 and the remainder on CPU 1. This problem occurs on both AMD V and VT. So, I guess the question is: (1) Is xenoprof reporting the correct CPU, or (2) Does "xm vcpu-pin" really do what it claims it does? Any ideas on this? For the moment, I'm ignoring the issue, but I would like it better if I could isolate the VCPU's to a dedicated CPU in order to reduce measurement overhead in the guest. (e. g. by forcing the trace daemon to run on CPU 0 and the measured guest to run on CPU 1.) BTW, this is on changeset 13062. -- Ray Bryant AMD Performance Labs Austin, Tx 512-602-0038 (o) 512-507-7807 (c)