From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Egger Subject: Re: [PATCH 0 of 5] v2: Nested-p2m cleanups and locking changes Date: Tue, 28 Jun 2011 13:04:00 +0200 Message-ID: <4E09B520.7020900@amd.com> References: <20110627105654.GK17634@whitby.uk.xensource.com> <4E08762A.2050801@amd.com> <20110627131528.GN17634@whitby.uk.xensource.com> <20110627154831.GS17634@whitby.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20110627154831.GS17634@whitby.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Tim Deegan Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On 06/27/11 17:48, Tim Deegan wrote: > At 14:15 +0100 on 27 Jun (1309184128), Tim Deegan wrote: >> At 14:23 +0200 on 27 Jun (1309184586), Christoph Egger wrote: >>>> - Why is there a 10x increase in IPIs after this series? I don't see >>>> what sequence of events sets the relevant cpumask bits to make this >>>> happen. >>> >>> In patch 1 the code that sends the IPIs was outside of the loop and >>> moved into the loop. >> >> Well, yes, but I don't see what that causes 10x IPIs, unless the vcpus >> are burning through np2m tables very quickly indeed. Maybe removing the >> extra flushes for TLB control will do the trick. I'll make a patch... > > I think I get it - it's a race between p2m_flush_nestedp2m() on one CPU > flushing all the nested P2M tables and a VCPU on another CPU repeatedly > getting fresh ones. Try the attached patch, which should cut back the > major source of p2m_flush_nestedp2m() calls. This patch is great! It gives the speed up the XP mode needs to continue booting. We talked about this at the Xen-Hackathon you remember? > Writing it, I realised that after my locking fix, p2m_flush_nestedp2m() > isn't safe because it can run in parallel with p2m_get_nestedp2m, which > reorders the array it walks. I'll have to make the LRU-fu independent > of the array order; should be easy enough but I'll hold off committing > the current series until I've done it. Ok. Christoph -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85689 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632