[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |