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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

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