On Tue, 2007-08-21 at 16:05 +1000, Dave Airlie wrote:
So you can see why some sort of uncached+writecombined page cache
would be useful, I could just allocate a bunch of pages at startup as
uncached+writecombined, and allocate pixmaps from them and when I
bind/free the pixmap I don't need the
On Sun, 2008-08-24 at 21:57 +0100, Dave Airlie wrote:
Quite frankly, I'm not going to take this.
None of what you describe sounds like regressions, and this is just TOO
F*CKING LATE to take big changes like this, to a fragile subsystem that
has historically easily introduced new
On Mon, 2008-08-25 at 08:49 +0200, Peter Zijlstra wrote:
On Sun, 2008-08-24 at 21:57 +0100, Dave Airlie wrote:
Quite frankly, I'm not going to take this.
None of what you describe sounds like regressions, and this is just TOO
F*CKING LATE to take big changes like this, to a fragile
On Sat, 2008-10-18 at 00:49 -0700, Eric Anholt wrote:
Writing 3D drivers means running 3D games. Running 3D games
unfortunately means running a lot of 32-bit userland as the fun stuff is
binary-only. So I stick to a 32-bit system, becuase past experience
trying to run both on the same
On Tue, 2009-02-17 at 16:59 -0800, Eric Anholt wrote:
The basic problem was
mmap_sem (do_mmap()) - struct_mutex (drm_gem_mmap(), i915_gem_fault())
struct_mutex (i915_gem_execbuffer()) - mmap_sem (copy_from/to_user())
That's not the only problem, there's also:
dup_mmap()
down_write(mmap_sem)
On Wed, 2009-02-18 at 11:38 -0500, k...@bitplanet.net wrote:
From: Kristian Høgsberg k...@redhat.com
A number of GEM operations (and legacy drm ones) want to copy data to
or from userspace while holding the struct_mutex lock. However, the
fault handler calls us with the mmap_sem held and
On Thu, 2009-02-19 at 10:19 +0100, Peter Zijlstra wrote:
On Wed, 2009-02-18 at 11:38 -0500, k...@bitplanet.net wrote:
From: Kristian Høgsberg k...@redhat.com
A number of GEM operations (and legacy drm ones) want to copy data to
or from userspace while holding the struct_mutex lock
On Thu, 2009-02-19 at 22:02 +0100, Thomas Hellstrom wrote:
It looks to me like the driver preferred locking order is
object_mutex (which happens to be the device global struct_mutex)
mmap_sem
offset_mutex.
So if one could avoid using the struct_mutex for object bookkeeping (A
On Thu, 2009-02-19 at 18:04 -0800, Eric Anholt wrote:
On Thu, 2009-02-19 at 23:26 +0100, Peter Zijlstra wrote:
On Thu, 2009-02-19 at 22:02 +0100, Thomas Hellstrom wrote:
It looks to me like the driver preferred locking order is
object_mutex (which happens to be the device global
On Fri, 2009-02-20 at 09:31 +0100, Thomas Hellstrom wrote:
Peter Zijlstra wrote:
On Thu, 2009-02-19 at 22:02 +0100, Thomas Hellstrom wrote:
It looks to me like the driver preferred locking order is
object_mutex (which happens to be the device global struct_mutex)
mmap_sem
On Wed, 2009-02-25 at 00:15 -0800, Eric Anholt wrote:
Or you could get_user_pages() to fault the user pages and pin them, and
then do pagefault_disable() and use copy_from_user_inatomic or such, and
release the pages again.
I started poking at this today, since the get_user_pages sounded
On Fri, 2009-02-27 at 10:28 +0100, Jiri Slaby wrote:
SysRq : Show Locks Held
Showing all locks held in the system:
3 locks held by events/0/10:
#0: (events){+.+.+.}, at: [8025223d] worker_thread+0x19d/0x340
#1: ((dev_priv-mm.retire_work)-work){+.+...}, at: [8025223d]
On Sat, 2009-03-28 at 09:46 +0100, Brice Goglin wrote:
Peter Zijlstra wrote:
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
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
On Sat, 2009-03-28 at 13:22 +0100, Peter Zijlstra wrote:
I'm not really trusting my brain today, but something like the below
should work I think.
Nick, any thoughts?
Not-Signed-off-by: Peter Zijlstra a.p.zijls...@chello.nl
---
arch/x86/mm/gup.c | 24 +---
1
On Thu, 2009-03-26 at 17:43 -0700, Jesse Barnes wrote:
On Wed, 25 Mar 2009 14:45:05 -0700
Eric Anholt e...@anholt.net wrote:
Since the pagefault path determines that the lock order we use has to
be mmap_sem - struct_mutex, we can't allow page faults to occur
while the struct_mutex is
On Sat, 2009-03-28 at 11:48 +0100, Peter Zijlstra wrote:
On Sat, 2009-03-28 at 09:46 +0100, Brice Goglin wrote:
Peter Zijlstra wrote:
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
On Tue, 2009-05-26 at 12:27 -0400, Kyle McMartin wrote:
From: Kyle McMartin k...@redhat.com
Ensure we allocate GEM objects below 4GB on PAE machines, otherwise
misery ensues. This patch is based on a patch found on dri-devel by
Shaohua Li, but Keith P. expressed reticence that the changes
On Tue, 2009-05-26 at 14:35 -0700, Eric Anholt wrote:
On Tue, 2009-05-26 at 21:17 +0200, Peter Zijlstra wrote:
On Tue, 2009-05-26 at 12:27 -0400, Kyle McMartin wrote:
From: Kyle McMartin k...@redhat.com
Ensure we allocate GEM objects below 4GB on PAE machines, otherwise
misery
On Mon, 2009-06-22 at 19:26 +0200, Jerome Glisse wrote:
We don't need to allocated contiguous pages in cs codepath
so use vmalloc instead.
Best would be to not require PAGE_SIZE allocations at all of course.
But barring that, it would be great to have something like:
ptr = kmalloc(size,
On Tue, 2009-06-23 at 21:42 +1000, Dave Airlie wrote:
On Tue, Jun 23, 2009 at 9:35 PM, Peter Zijlstrapet...@infradead.org wrote:
On Mon, 2009-06-22 at 19:26 +0200, Jerome Glisse wrote:
We don't need to allocated contiguous pages in cs codepath
so use vmalloc instead.
Best would be to
On Tue, 2009-09-22 at 19:12 +0800, Xiaotian Feng wrote:
Hi,
I used today's git tree with FC11 configs plus some debug configs,
then I found my FC11 can not startx anymore... Each time I run
startx, I'll get a Fatal error:
(EE) Screen(s) found, but none have a usable
Hi Dave,
I was wondering about the current state of Radeon KMS, how far are we
from having it removed from staging?
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your
On Wed, 2009-11-11 at 09:14 +, Dave Airlie wrote:
Hi Dave,
I was wondering about the current state of Radeon KMS, how far are we
from having it removed from staging?
I'm sort of thinking the next merge window of moving the enable option
into the kernel proper. We still have a
On Tue, 2012-08-21 at 10:15 +0100, Alan Cox wrote:
So after much tracing with direct netconsole writes (printks
under console_lock not so useful), I think I found the race.
Direct netconsole write would be a useful patch to have mainline I think
8)
could we make that use the earlyprintk
25 matches
Mail list logo
