From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andre Przywara Subject: Re: [PATCH] Avoid race when moving cpu between cpupools Date: Fri, 25 Feb 2011 15:25:30 +0100 Message-ID: <4D67BBDA.5070603@amd.com> References: <5485071c8b0a6a49f65b.1298541625@nehalem1> <4D666678.1000301@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Juergen Gross Cc: George Dunlap , "xen-devel@lists.xensource.com" , Keir Fraser , "Diestelhorst, Stephan" List-Id: xen-devel@lists.xenproject.org George Dunlap wrote: > Looks good -- thanks Juergen. > > Acked-by: George Dunlap > > -George > > On Thu, Feb 24, 2011 at 2:08 PM, Andre Przywara wrote: >> Juergen Gross wrote: >>> Moving cpus between cpupools is done under the schedule lock of the moved >>> cpu. >>> When checking a cpu being member of a cpupool this must be done with the >>> lock >>> of that cpu being held. >> I have reviewed and tested the patch. It fixes my problem. My script has >> been running for several hundred iterations without any Xen crash, whereas >> without the patch the hypervisor crashed mostly at the second iteration. Juergen, can you rule out that this code will be triggered on two CPUs trying to switch to each other? As Stephan pointed out: the code looks like as this could trigger a possible dead-lock condition, where: 1) CPU A grabs lock (a) while CPU B grabs lock (b) 2) CPU A tries to grab (b) and CPU B tries to grab (a) 3) both fail and loop to 1) A possible fix would be to introduce some ordering for the locks (just the pointer address) and let the "bigger" pointer yield to the "smaller" one. I am not sure if this is really necessary, but I now see strange hangs after running the script for a while (30min to 1hr). Sometimes Dom0 hangs for a while, loosing interrupts (sda or eth0) or getting spurious ones, on two occasions the machine totally locked up. I am not 100% sure whether this is CPUpools related, but I put some load on Dom0 (without messing with CPUpools) for the whole night and it ran fine. Sorry for this :-( I will try to further isolate this. Anyway, it works much better with the fix than without and I will try to trigger this with the "reduce number of Dom0 vCPUs" patch. Regards, Andre. >> >> Thanks Juergen and George for the persistent work! >> >>> Hot-unplugging of physical cpus might encounter the same problems, but >>> this >>> should happen only very rarely. >>> >>> Signed-off-by: juergen.gross@ts.fujitsu.com >> Acked-by: Andre Przywara >> >> Keir, please apply for 4.1.0. >> -- Andre Przywara AMD-OSRC (Dresden) Tel: x29712