drm_clflush_pages performance

drm_clflush_pages performance

[hank peng]

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?


-- 
The simplest is not all best but the best is surely the simplest!

Re: drm_clflush_pages performance

[Dave Airlie]

On Sat, Sep 15, 2012 at 10:41 AM, hank peng <pengxihan@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.

Dave.

Re: drm_clflush_pages performance

[Chris Wilson]

On Sat, 15 Sep 2012 18:06:03 -0400, Dave Airlie <airlied@gmail.com> wrote:
> On Sat, Sep 15, 2012 at 10:41 AM, hank peng <pengxihan@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

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: drm_clflush_pages performance

[Ben Widawsky]

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

> On Sat, 15 Sep 2012 18:06:03 -0400, Dave Airlie <airlied@gmail.com> wrote:
> > On Sat, Sep 15, 2012 at 10:41 AM, hank peng <pengxihan@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