[Intel-gfx] drm_clflush_pages performance

[Ben Widawsky]

On Sun, 16 Sep 2012 08:12:46 +0100
Chris Wilson <chris at chris-wilson.co.uk> wrote:

> On Sat, 15 Sep 2012 18:06:03 -0400, Dave Airlie <airlied at gmail.com> wrote:
> > On Sat, Sep 15, 2012 at 10:41 AM, hank peng <pengxihan at gmail.com> wrote:
> > > I noticed that drm_clflush_pages function will first choose clfush
> > > instead of wbinvd, its code like this:
> > >
> > > void
> > > drm_clflush_pages(struct page *pages[], unsigned long num_pages)
> > > {
> > >
> > > #if defined(CONFIG_X86)
> > >         if (cpu_has_clflush) {
> > >                 drm_cache_flush_clflush(pages, num_pages);
> > >                 return;
> > >         }
> > >
> > >         if (on_each_cpu(drm_clflush_ipi_handler, NULL, 1) != 0)
> > >                 printk(KERN_ERR "Timed out waiting for cache flush.\n");
> > >
> > >
> > > I think using clfush will be slower than using wbinvd, so I wonder if
> > > I use wbinvd first, what else impact will it bring?
> > 
> > clflush is faster than wbinvd for a lot use cases,
> > 
> > There may be a threshold point where it makes sense to wbinvd, but it
> > will affect all processes using the cache not just ones using the
> > specific pages.
> 
> The other factor is that on recent machines the cost of
> smp_function_call() outweighs the cost of flushing the cache to memory.
> I made the unfortunate mistake of accidentally enabling the wbinvd path
> recently...
> -Chris
> 

Maybe it makes some sense based on the object size. For example, if we
had a 1GB bo, it might make more sense to wbinvd.

-- 
Ben Widawsky, Intel Open Source Technology Center