Re: [PATCH] drm: i915: ensure objects are allocated below 4GB on PAE
On Thu, May 28, 2009 at 01:40:12AM +0800, Eric Anholt wrote: On Wed, 2009-05-27 at 08:42 +0800, Shaohua Li wrote: On Wed, May 27, 2009 at 08:18:40AM +0800, Kyle McMartin wrote: On Tue, May 26, 2009 at 11:55:50PM +0100, Hugh Dickins wrote: I'm confused: I thought GFP_DMA32 only applies on x86_64: my 32-bit PAE machine with (slightly!) 4GB shows no ZONE_DMA32. Does this patch perhaps depend on another, to enable DMA32 on 32-bit PAE, or am I just in a muddle? No, you're exactly right, I'm just a muppet and missed the obvious. Looks like the correct fix is the fact that the allocation is thus filled out with GFP_USER, therefore, from ZONE_NORMAL, and below max_low_pfn. Looks like we'll need some additional thinking to get true ZONE_DMA32 on i386... ugh, I'll look into it tonight. For i386, GFP_USER is enough. But 945G GART can only map to physical page 4G, so for x64, we need GFP_DMA32. This is the reason I add extra GFP_DMA32. Those 945Gs don't have memory located above 4G, from my reading of the chipset specs. ok, then GFP_DMA32 can be removed from the patch. -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://p.sf.net/sfu/creativitycat-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: i915: ensure objects are allocated below 4GB on PAE
On Wed, May 27, 2009 at 08:18:40AM +0800, Kyle McMartin wrote: On Tue, May 26, 2009 at 11:55:50PM +0100, Hugh Dickins wrote: I'm confused: I thought GFP_DMA32 only applies on x86_64: my 32-bit PAE machine with (slightly!) 4GB shows no ZONE_DMA32. Does this patch perhaps depend on another, to enable DMA32 on 32-bit PAE, or am I just in a muddle? No, you're exactly right, I'm just a muppet and missed the obvious. Looks like the correct fix is the fact that the allocation is thus filled out with GFP_USER, therefore, from ZONE_NORMAL, and below max_low_pfn. Looks like we'll need some additional thinking to get true ZONE_DMA32 on i386... ugh, I'll look into it tonight. For i386, GFP_USER is enough. But 945G GART can only map to physical page 4G, so for x64, we need GFP_DMA32. This is the reason I add extra GFP_DMA32. Thanks, Shaohua -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://p.sf.net/sfu/creativitycat-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[RFC]DRM: limit gem object memory below 4G
Limit gem object mapping to below 4G. This fixes two issues: 1. remove limit that gem can't be enabled with PAE 2. in x64, shmem page can be higher than 4G, but for example, 945G GTT mapping can only handle 4G mapping. Am I missing anything? Signed-off-by: Shaohua Li shaohua...@intel.com --- drivers/gpu/drm/drm_gem.c |1 + drivers/gpu/drm/i915/i915_dma.c |6 -- mm/shmem.c |2 +- 3 files changed, 2 insertions(+), 7 deletions(-) Index: linux/drivers/gpu/drm/drm_gem.c === --- linux.orig/drivers/gpu/drm/drm_gem.c2009-05-19 14:27:12.0 +0800 +++ linux/drivers/gpu/drm/drm_gem.c 2009-05-19 14:29:47.0 +0800 @@ -141,6 +141,7 @@ drm_gem_object_alloc(struct drm_device * kfree(obj); return NULL; } + mapping_set_gfp_mask(obj-filp-f_mapping, GFP_USER|GFP_DMA32); kref_init(obj-refcount); kref_init(obj-handlecount); Index: linux/drivers/gpu/drm/i915/i915_dma.c === --- linux.orig/drivers/gpu/drm/i915/i915_dma.c 2009-05-19 14:27:12.0 +0800 +++ linux/drivers/gpu/drm/i915/i915_dma.c 2009-05-19 14:29:19.0 +0800 @@ -1152,13 +1152,7 @@ int i915_driver_load(struct drm_device * performance may suffer.\n); } -#ifdef CONFIG_HIGHMEM64G - /* don't enable GEM on PAE - needs agp + set_memory_* interface fixes */ - dev_priv-has_gem = 0; -#else - /* enable GEM by default */ dev_priv-has_gem = 1; -#endif dev-driver-get_vblank_counter = i915_get_vblank_counter; if (IS_GM45(dev)) Index: linux/mm/shmem.c === --- linux.orig/mm/shmem.c 2009-05-19 14:39:11.0 +0800 +++ linux/mm/shmem.c2009-05-19 14:39:45.0 +0800 @@ -1241,7 +1241,7 @@ repeat: * Try to preload while we can wait, to not make a habit of * draining atomic reserves; but don't latch on to this cpu. */ - error = radix_tree_preload(gfp ~__GFP_HIGHMEM); + error = radix_tree_preload(gfp ~(__GFP_HIGHMEM|__GFP_DMA32)); if (error) goto failed; radix_tree_preload_end(); -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: PROBLEM: 2.6.29.2 - AGP doesn't work anymore on my nforce2
On Sun, May 17, 2009 at 07:44:20AM +0800, Andrew Morton wrote: On Mon, 04 May 2009 18:40:52 +0200 Michel D__nzer mic...@daenzer.net wrote: On Mon, 2009-05-04 at 18:23 +0200, Karsten Mehrhoff wrote: On Mon, 04 May 2009 17:07:40 +0200, Michel D__nzer wrote: On Mon, 2009-05-04 at 08:31 +0200, Karsten Mehrhoff wrote: On Mon, 04 May 2009 03:41:51 +0200, Shaohua Li wrote: On Fri, May 01, 2009 at 09:22:19PM +0800, kaw...@gmx.de wrote: On Thu, 2009-04-30 at 17:59 -0700, Andrew Morton wrote: On Thu, 30 Apr 2009 10:51:47 +0200 Karsten Mehrhoff wrote: [1.] PROBLEM: No more agp card functionality with the patch 2.6.29.2 of 'a/drivers/char/agp/generic.c' [2.] I compiled the kernel 2.6.29.2 with my .config of 2.6.29.1 and run into problems with the speed of my ATI RADEON 9600 (rv350) Is your problem speed issue ? ie just a slowdown ? Or does AGP stop working with this patch ? Slowdown is expected from this patch but it should hurt too much. 2.6.29.1 | 2.6.29.2 | glxgears ~ 2900 FPS | ~ 75 FPS glxgears -fullscreen ~ 500 FPS | ~ 11 FPS Does this patch alone give so huge slowdown? From my little knowledge, xserver does agp pages allocation only at startup. I only reverted this patch in the source file (/drivers/char/agp/generic.c) and got back my old speed on 2.6.29.2. Is the DRI enabled in both cases? Compare the Xorg.0.log file and the output of dmesg|grep -e agp -e drm * 2.6.29.2 (original) * $ dmesg|grep -e agp -e drm $ dmesg|grep agp [0.861997] Linux agpgart interface v0.103 [ 10.893793] agpgart: Detected NVIDIA nForce2 chipset [ 10.939070] agpgart-nvidia :00:00.0: AGP aperture is 64M @ 0xe000 No drm lines? $ glxinfo | grep direct direct rendering: Yes This is not a sufficient test anymore since swrast_dri.so is direct rendering but not hardware accelerated. Something like glxinfo|grep render can be used to verify both direct rendering and hardware acceleration (the latter but not the former is also possible with AIGLX). (EE) RADEON(0): [agp] AGP failed to initialize. Disabling the DRI. [...] For me it seems that agp failed to initialize because of the patch. Indeed. Guys, can we rev this up again please? AFAICT we have two problems and at least one of them is in 2.6.29.x and is presumably headed into 2.6.30 as well. the slowdown Karsten saw is because dri is disabled. I can't image why zero page will cause such issue. please double check if this is really caused by 59de2bebabc5027f93df999d59cc65df591c3e6e. Thanks, Shaohua -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: PROBLEM: 2.6.29.2 - AGP doesn't work anymore on my nforce2
On Fri, May 01, 2009 at 09:22:19PM +0800, kaw...@gmx.de wrote: On Thu, 2009-04-30 at 17:59 -0700, Andrew Morton wrote: On Thu, 30 Apr 2009 10:51:47 +0200 Karsten Mehrhoff kaw...@gmx.de wrote: [1.] PROBLEM: No more agp card functionality with the patch 2.6.29.2 of 'a/drivers/char/agp/generic.c' [2.] I compiled the kernel 2.6.29.2 with my .config of 2.6.29.1 and run into problems with the speed of my ATI RADEON 9600 (rv350) Is your problem speed issue ? ie just a slowdown ? Or does AGP stop working with this patch ? Slowdown is expected from this patch but it should hurt too much. 2.6.29.1 | 2.6.29.2 | glxgears ~ 2900 FPS | ~ 75 FPS glxgears -fullscreen ~ 500 FPS | ~ 11 FPS Does this patch alone give so huge slowdown? From my little knowledge, xserver does agp pages allocation only at startup. -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] drm: drm_lock possible error
On Fri, 2009-04-24 at 16:10 +0800, Thomas Hellstrom wrote:
Dave Airlie wrote:
On Wed, Apr 22, 2009 at 11:48 AM, Shaohua Li shaohua...@intel.com wrote:
drm_lock() does:
for (;;) {
__set_current_state(TASK_INTERRUPTIBLE);
...
if (drm_lock_take(master-lock, lock-context)) {
schedule() here
master-lock.file_priv = file_priv;
master-lock.lock_time = jiffies;
atomic_inc(dev-counts[_DRM_STAT_LOCKS]);
break; /* Got lock */
}
...
}
If a preempt occurs in marked line, the task already holds the lock but
set to interruptible, then nobody can wakeup the task (except signal) and
other tasks can't get the lock again. Am I missing anything?
Thomas you seem to have the best understanding of this code, can you
take a look and ack this?
Dave.
At a first glance this looks like a sane patch.
In essence what's said is that a TASK_INTERRUPTIBLE task must never be
preempted, because it might be that nobody's there to wake it up.
But we would've most likely hit the consequences by now, wouldn't we?
Also looking at similar code (for example __wait_event_interruptible) in
linux/wait.h there's no
preempt_disable.
Before we adopt this patch we'd need to understand why that is. Could it
be that the scheduler is
smart enough never to put (!TASK_RUNNING) processes to sleep when
they're preempted?
no. If yes, then the schedule() just below the code will report error.
I guess this is case by case. In this case, if no lock is taken, the
preempt() in interruptible is ok, because other thread will eventually
wake up the thread with a drm_unlock(). If the lock is taken, then
nobody can take drm lock, so nobody will call drm_unlock()
Thanks,
Shaohua
--
Crystal Reports #45; New Free Runtime and 30 Day Trial
Check out the new simplified licensign option that enables unlimited
royalty#45;free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[RFC] drm: drm_lock possible error
drm_lock() does:
for (;;) {
__set_current_state(TASK_INTERRUPTIBLE);
...
if (drm_lock_take(master-lock, lock-context)) {
schedule() here
master-lock.file_priv = file_priv;
master-lock.lock_time = jiffies;
atomic_inc(dev-counts[_DRM_STAT_LOCKS]);
break; /* Got lock */
}
...
}
If a preempt occurs in marked line, the task already holds the lock but
set to interruptible, then nobody can wakeup the task (except signal) and
other tasks can't get the lock again. Am I missing anything?
Signed-off-by: Shaohua Lishaohua...@intel.com
diff --git a/drivers/gpu/drm/drm_lock.c b/drivers/gpu/drm/drm_lock.c
index e2f70a5..32fbca0 100644
--- a/drivers/gpu/drm/drm_lock.c
+++ b/drivers/gpu/drm/drm_lock.c
@@ -76,6 +76,7 @@ int drm_lock(struct drm_device *dev, void *data, struct
drm_file *file_priv)
master-lock.user_waiters++;
spin_unlock_bh(master-lock.spinlock);
+ preempt_disable();
for (;;) {
__set_current_state(TASK_INTERRUPTIBLE);
if (!master-lock.hw_lock) {
@@ -90,18 +91,21 @@ int drm_lock(struct drm_device *dev, void *data, struct
drm_file *file_priv)
atomic_inc(dev-counts[_DRM_STAT_LOCKS]);
break; /* Got lock */
}
+ preempt_enable_no_resched();
/* Contention */
schedule();
+ preempt_disable();
if (signal_pending(current)) {
ret = -EINTR;
break;
}
}
+ __set_current_state(TASK_RUNNING);
+ preempt_enable();
spin_lock_bh(master-lock.spinlock);
master-lock.user_waiters--;
spin_unlock_bh(master-lock.spinlock);
- __set_current_state(TASK_RUNNING);
remove_wait_queue(master-lock.lock_queue, entry);
DRM_DEBUG(%d %s\n, lock-context,
--
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
