From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Andres Lagar-Cavilla" Subject: Re: lock in vhpet Date: Tue, 24 Apr 2012 19:31:26 -0700 Message-ID: References: <20120419082717.GA23663@ocelot.phlegethon.org> <20120423091445.GA17920@ocelot.phlegethon.org> <2a7b92d7a952c53c0fb81bdebdd45d24.squirrel@webmail.lagarcavilla.org> <20120424091646.GB34721@ocelot.phlegethon.org> <958f5bfcc3ae6a631cf7208086553dce.squirrel@webmail.lagarcavilla.org> Reply-To: andres@lagarcavilla.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Zhang, Yang Z" Cc: Keir Fraser , "xen-devel@lists.xensource.com" , Tim Deegan List-Id: xen-devel@lists.xenproject.org > >> -----Original Message----- >> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org] >> Sent: Wednesday, April 25, 2012 9:40 AM >> To: Zhang, Yang Z >> Cc: Tim Deegan; xen-devel@lists.xensource.com; Keir Fraser >> Subject: RE: [Xen-devel] lock in vhpet >> >> >> -----Original Message----- >> >> From: Tim Deegan [mailto:tim@xen.org] >> >> Sent: Tuesday, April 24, 2012 5:17 PM >> >> To: Zhang, Yang Z >> >> Cc: andres@lagarcavilla.org; xen-devel@lists.xensource.com; Keir >> >> Fraser >> >> Subject: Re: [Xen-devel] lock in vhpet >> >> >> >> At 08:58 +0000 on 24 Apr (1335257909), Zhang, Yang Z wrote: >> >> > > -----Original Message----- >> >> > > From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org] >> >> > > Sent: Tuesday, April 24, 2012 1:19 AM >> >> > > >> >> > > Let me know if any of this helps >> >> > No, it not works. >> >> >> >> Do you mean that it doesn't help with the CPU overhead, or that it's >> >> broken in some other way? >> >> >> > It cannot help with the CPU overhead >> >> Yang, is there any further information you can provide? A rough idea of >> where >> vcpus are spending time spinning for the p2m lock would be tremendously >> useful. >> > I am doing the further investigation. Hope can get more useful > information. Thanks, looking forward to that. > But actually, the first cs introduced this issue is 24770. When win8 > booting and if hpet is enabled, it will use hpet as the time source and > there have lots of hpet access and EPT violation. In EPT violation > handler, it call get_gfn_type_access to get the mfn. The cs 24770 > introduces the gfn_lock for p2m lookups, and then the issue happens. After > I removed the gfn_lock, the issue goes. But in latest xen, even I remove > this lock, it still shows high cpu utilization. > It would seem then that even the briefest lock-protected critical section would cause this? In the mmio case, the p2m lock taken in the hap fault handler is held during the actual lookup, and for a couple of branch instructions afterwards. In latest Xen, with lock removed for get_gfn, on which lock is time spent? Thanks, Andres > yang >