Re: [Xen-devel] lock in vhpet

["Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>]

Hi tim,

Did the attached patch apply to upstream xen? I tried the latest xen and still 
saw the high cpu utilization.

best regards
yang

> -----Original Message-----
> From: Tim Deegan [mailto:tim@xxxxxxx]
> Sent: Friday, April 27, 2012 5:26 AM
> To: Zhang, Yang Z
> Cc: andres@xxxxxxxxxxxxxxxx; Keir Fraser; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] lock in vhpet
> 
> At 02:36 +0000 on 25 Apr (1335321409), Zhang, Yang Z wrote:
> > > > 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?
> > Still the p2m_lock.
> 
> Can you please try the attached patch?  I think you'll need this one
> plus the ones that take the locks out of the hpet code.
> 
> This patch makes the p2m lock into an rwlock and adjusts a number of the
> paths that don't update the p2m so they only take the read lock.  It's a
> bit rough but I can boot 16-way win7 guest with it.
> 
> N.B. Since rwlocks don't show up the the existing lock profiling, please
> don't try to use the lock-profiling numbers to see if it's helping!
> 
> Andres, this is basically the big-hammer version of your "take a
> pagecount" changes, plus the change you made to hvmemul_rep_movs().
> If this works I intend to follow it up with a patch to make some of the
> read-modify-write paths avoid taking the lock (by using a
> compare-exchange operation so they only take the lock on a write).  If
> that succeeds I might drop put_gfn() altogether.
> 
> But first it will need a lot of tidying up.  Noticeably missing:
>  - SVM code equivalents to the vmx.c changes
>  - grant-table operations still use the lock, because frankly I
>    could not follow the current code, and it's quite late in the evening.
> I also have a long list of uglinesses in the mm code that I found while
> writing this lot.
> 
> Keir, I have no objection to later replacing this with something better
> than an rwlock. :)  Or with making a NUMA-friendly rwlock
> implementation, since I really expect this to be heavily read-mostly
> when paging/sharing/pod are not enabled.
> 
> Cheers,
> 
> Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel