On Tue, Jan 06, 2009 at 05:33:36PM -0800, Pallipadi, Venkatesh wrote:
> On Tue, Jan 06, 2009 at 11:05:51AM -0800, Pallipadi, Venkatesh wrote:
> > 
> >  
> > 
> > >-----Original Message-----
> > >From: H. Peter Anvin [mailto:hpa@zytor.com] 
> > >Sent: Tuesday, January 06, 2009 10:52 AM
> > >To: Alexey Fisher
> > >Cc: kernel-testers-owner@vger.kernel.org; 
> > >linux-kernel@vger.kernel.org; Siddha, Suresh B; Pallipadi, Venkatesh
> > >Subject: Re: [regression] glx performance drop with: "x86: 
> > >PAT: implement track/untrack of pfnmap regions for x86 - v3"
> > >
> > >Alexey Fisher wrote:
> > >> glx perfomance regression after this patch.
> > >> goot kernel: glxgears = 1400 fps
> > >> bad kernel: glxgears = 300 fps ( same speed with disabled 
> > >drm module )
> > >> 
> > >> kernel log:
> > >> glxgears:5775 map pfn expected mapping type write-back for
> > >> d1000000-d1c80000, got uncached-minus
> > >> glxgears:5775 freeing invalid memtype d1000000-d1c80000
> > >> 
> > >
> > >Have we caught a case of actual overlap, i.e. a driver bug here?
> > >
> > 
> > This error is similar to one reported by Kevin here.
> > http://lkml.indiana.edu/hypermail/linux/kernel/0901.0/00970.html
> > [  111.775378] X:5010 map pfn expected mapping type write-back for d0000000-d0101000, got write-combining
> > [  111.775456] X:5010 freeing invalid memtype d0000000-d0101000
> > 
> > 
> > The sequence seems to be somewhat like this
> > 
> > - Kernel driver sets the whole graphics region to uc-minus or write-combining
> > - There is a remap_pfn_range() to map a portion of this region to user with "write-back" mapping.
> > 
> > Now there may be a MTRR for this region or there may be none. It will depend on specific system and
> > whether there were available MTRRs or MTRR setting was possible at all.If there are no MTRR settings,
> > then we have caught a valid aliasing here.
> > 
> > I have reproduced this problem on a local system here and looking for a sane solution....
> >
> 
> Looks like there is more than one problem with glxgears with latest git.
> 
> Below test patch fixes the memory type conflicts with remap_pfn_range. But,
> with this test patch applied to latest git, glxgears does not work on my
> test system. It goes into a repeaed ioctl(4, 0x40046445, ..) loop.
> 
> But, with
> vanilla 2.6.28 + earlier pfnmap tracking patchset v3
> I do see lower performance of glxgears compared to vanilla 2.6.28.
> 
> and with
> vanilla 2.6.28 + earlier pfnmap tracking patchset v3 + test patch below
> brings the glxgears performance back to vanilla 2.6.28 level.
> 
> 
> Dave: Do you know of any other drm changes post 2.6.28 that may be resulting
> in glxgears getting stuck with above ioctl?

Dave,

I did a git bisect to root cause the second problem of glxgears hanging
and it points me to

--
7c1c2871a6a3a114853ec6836e9035ac1c0c7f7a is first bad commit
commit 7c1c2871a6a3a114853ec6836e9035ac1c0c7f7a
Author: Dave Airlie <airlied@redhat.com>
Date:   Fri Nov 28 14:22:24 2008 +1000

    drm: move to kref per-master structures.
    
    This is step one towards having multiple masters sharing a drm
    device in order to get fast-user-switching to work.
    
    It splits out the information associated with the drm master
    into a separate kref counted structure, and allocates this when
    a master opens the device node. It also allows the current master
    to abdicate (say while VT switched), and a new master to take over
    the hardware.
    
    It moves the Intel and radeon drivers to using the sarea from
    within the new master structures.
    
    Signed-off-by: Dave Airlie <airlied@redhat.com>
--

I could not check with this patch removed from latest git as there are some
dependencies. But, checkout of 7c1c2871a6a3 indeed has the problem of glxgears
hanging. My test system is a T61 with FC8 base installation and attached is my
config.

Thanks,
Venki