From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ryan Harper Subject: Re: pinning, tsc and apic Date: Tue, 13 May 2008 13:56:53 -0500 Message-ID: <20080513185653.GA20029@us.ibm.com> References: <20080512191923.GU17938@us.ibm.com> <48289F36.8020702@codemonkey.ws> <20080512212319.GV17938@us.ibm.com> <4828BA49.6060007@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel@lists.sourceforge.net, Ryan Harper To: Anthony Liguori Return-path: Content-Disposition: inline In-Reply-To: <4828BA49.6060007@codemonkey.ws> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces@lists.sourceforge.net Errors-To: kvm-devel-bounces@lists.sourceforge.net List-Id: kvm.vger.kernel.org * Anthony Liguori [2008-05-12 17:00]: > Ryan Harper wrote: > >>BTW, what if you don't pace-out the startups? Do we still have issues > >>with that? > >> > > > >Do you mean without the 1 second delay or with a longer delay? My > >experience is that delay helps (fewer hangs), but doesn't solve things > >completely. > > > > So you see problems when using numactrl to pin and using a 0-second > delay? The short delay may help reduce the number of CPU migrations > which would explain your observation. > > If there are problems when doing a 0-second delay and numactl, then > perhaps it's not just a cpu-migration issue. nodelay, w/pinning -> all OK delay, w/pinning -> all OK with -no-kvm-irqchip (with or without any delay (1 to 30 seconds), I get in some guests: ..MP-BIOS bug: 8254 timer not connected to IO-APIC Kernel panic - not syncing: IO-APIC + timer doesn't work! Try using the 'noapic' kernel parameter > >In svm.c, I do think we account for most of that time since the delta > >calculation will shift the guest time forward to the tsc value read in > >svm_vcpu_load(). We'll still miss the time between fixing the offset > >and when the guest can actually read its tsc. > > > > Yes, which is the duration that the guest isn't scheduled on any > processor and the next time it runs happens to be on a different process. > > >>A possible way to fix this (that's only valid on a processor with a > >>fixed-frequency TSC), is to take a high-res timestamp on vcpu_put, and > >>then on vcpu_load, take the delta timestamp since the old TSC was saved, > >>and use the TSC frequency on the new pcpu to calculate the number of > >>elapsed cycles. > >> > >>Assuming a fixed frequency TSC, and a calibrated TSC across all > >>processors, you could get the same affects by using the VT tsc delta > >>logic. Basically, it always uses the new CPU's TSC unless that would > >>cause the guest to move backwards in time. As long as you have a > >>stable, calibrated TSC, this would work out. > >> > >>Can you try your old patch that did this and see if it fixes the problem? > >> > > > >Yeah, I'll give it a spin. Testing the old patch with no-pinning, but just the tsc check doesn't help the situation. -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx (512) 838-9253 T/L: 678-9253 ryanh@us.ibm.com ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/