[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1238394572.9782.13.camel@gaiman.anholt.net>
Date: Sun, 29 Mar 2009 23:29:32 -0700
From: Eric Anholt <eric@...olt.net>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
dri-devel@...ts.sourceforge.net,
Nick Piggin <nickpiggin@...oo.com.au>
Subject: Re: DRM lock ordering fix series
On Sat, 2009-03-28 at 02:29 +0100, Peter Zijlstra wrote:
> On Sat, 2009-03-28 at 01:58 +0100, Peter Zijlstra wrote:
>
> > > OK. I'm not too excited here -- 10% of 2% of the CPU time doesn't get
> > > me to the 10% loss that the slow path added up to. Most of the cost is
> > > in k{un,}map_atomic of the returned pages.
> >
> > Also note that doing large gup() with gup_fast() will be undesirable due
> > to it disabling IRQs. So iterating say several MB worth of pages will
> > hurt like crazy. Currently all gup_fast() users do a single page lookup.
>
> Also, what's this weird facination with 32bit, can you even buy a 32bit
> only cpu these days?
I work on OpenGL. Many people using OpenGL want to play commercial
games. Commercial games are 32-bit. sysprof doesn't work for 32-on-64,
so I'd lose a critical tool. Thus, 32-only.
keithp runs 32-on-64, and just about every day we're working together,
we lament that he can't run sysprof on his box. Getting ~10% of my CPU
back by going 32-on-64 would be nice, but it's not worth not being able
to usefully profile.
--
Eric Anholt
eric@...olt.net eric.anholt@...el.com
Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)
Powered by blists - more mailing lists