[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] x86: consolidate/enhance TLB flushing interface


  • To: Jan Beulich <jbeulich@xxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Wed, 17 Oct 2007 08:21:00 +0100
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 17 Oct 2007 00:16:44 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcgQjkR1gsUOJ3yBEdy+GQAWy6hiGQ==
  • Thread-topic: [Xen-devel] [PATCH] x86: consolidate/enhance TLB flushing interface

On 17/10/07 08:15, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

>> Applied at last. I just changed the names of a few functions and added a few
>> comments. Also, I don't know whether you empirically evaluated CLFLUSH
>> versus WBINVD, but your CLFLUSH loop was actually broken because 'sz' was in
>> pages rather than bytes. Hence you did not CLFLUSH a big enough area (by a
>> large margin) and hence you would vastly underestimate the cost of the
>> CLFLUSH approach.
> 
> Oh, good you caught this. But no, I didn't do any measurements, I just
> wanted to cut off at the point where it is sufficiently sure using wbinvd
> wouldn't be slower than looping over clflush, which I estimated at the
> point where more data needs flushing than the cache can hold (of course,
> if what is being flushed hasn't been referenced recently, this may still
> be wrong, but otoh potentially flushing hundreds of megabytes in a loop
> seemed wasteful - L2 [or L3 is present] cache size is likely already larger
> than the real cutoff point, which in turn cannot reasonably be determined
> empirically as it likely depends on the amount of hits the clflush-es would
> have).

Fair enough. I believe that CLFLUSH of a few megabytes is unlikely to be
slower than WBINVD (which is really really slow!).

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.