On Fri, 2004-08-20 at 19:23, Fernando Pablo Lopez-Lezcano wrote:
> Here's a new one, this is 2.6.8.1 (NOT 2.4.8.1!, sigh) + voluntary P6,
> voluntary+kernel preemption enabled, threaded = 0 for the soundcard.
> ALSA
> /usr/src/redhat/BUILD/alsa-driver-1.0.6a/alsa-kernel/core/pcm_lib.c:139:
> XRUN:
The delay is very large because this routine is waiting for the
graphics coprocessor to finish an operation. Some of the operations can
take many ms to complete; for example telling the chip to copy 64MB of
memory somewhere. I would think the question should be, how do we wait
on the GPU without ki
>
> It looks like the timeout for many Radeon DRI operations is controlled
> by the dev_priv->usec_timeout value, which is copied from userspace via
> ioctl in radeon_cp_init. This value can be as large as 100 MSECS!
>
> radeon_drv.h:#define RADEON_MAX_USEC_TIMEOUT 10 /* 100 ms */
>
I don't believe the DRM drivers are holding any global kernel locks
when they do wait_for_fifo. Any locks held would be internal to DRM and
can be changed if needed.
--- Lee Revell <[EMAIL PROTECTED]> wrote:
> On Sat, 2004-08-21 at 01:29, Jon Smirl wrote:
>
> > What's the right way to write a lo
* Jon Smirl <[EMAIL PROTECTED]> wrote:
> A better solution might be to loop twenty times to pick up the very
> short commands. After 20us switch to a loop that allows the kernel to
> schedule. You don't want to immediately schedule since that will kill
> graphics performance.
You can busy-loop j
On Sat, 2004-08-21 at 01:37, Dave Airlie wrote:
> >
> > It looks like the timeout for many Radeon DRI operations is controlled
> > by the dev_priv->usec_timeout value, which is copied from userspace via
> > ioctl in radeon_cp_init. This value can be as large as 100 MSECS!
> >
> > radeon_drv.h:#def
On Fri, 2004-08-20 at 22:59 -0700, Jon Smirl wrote:
> I don't believe the DRM drivers are holding any global kernel locks
> when they do wait_for_fifo. Any locks held would be internal to DRM and
> can be changed if needed.
Keep in mind that any ioctl function runs with the Big Kernel Lock held.
On Sat, 2004-08-21 at 01:29, Jon Smirl wrote:
> What's the right way to write a loop like this that meets the above
> requirements and also satisfies the audio needs?
>
I think it depends on which locks you are holding, and what kind of
locks they are.
Lee
---
>
> Keep in mind that any ioctl function runs with the Big Kernel Lock held.
so were screwed? or should we just drop the BKL inside our ioctls? I think
the DRM locking should be good enough and if it isn't it should be made
good enough..
just in case anyone is wondering nearly all DRI stuff is do
--- Ingo Molnar <[EMAIL PROTECTED]> wrote:
> the cleanest and highest performing solution would be to have an
> interrupt source for 3D completion - do you have such an interrupt
> handler handy? If yes then you can sleep precisely up to completion:
Interrupts are not a good solution. The hardware
Michel pointed out that all IOCTL calls hold the big kernel lock.
Releasing this lock is sure to case problems since the DRM code is not
designed to be reentrant. I don't know what it will take to fix locking
to allow this, maybe one of the original DRM authors will pop in here
with the answer. Unt
On Sad, 2004-08-21 at 16:00, Michel DÃnzer wrote:
> On Fri, 2004-08-20 at 22:59 -0700, Jon Smirl wrote:
> > I don't believe the DRM drivers are holding any global kernel locks
> > when they do wait_for_fifo. Any locks held would be internal to DRM and
> > can be changed if needed.
>
> Keep in mind
On Sul, 2004-08-22 at 02:51, Jon Smirl wrote:
> Michel pointed out that all IOCTL calls hold the big kernel lock.
> Releasing this lock is sure to case problems since the DRM code is not
> designed to be reentrant.
That lock is already released whenever the code sleeps (eg page faults)
so if its b
On Sat, 2004-08-21 at 15:25, Fernando Pablo Lopez-Lezcano wrote:
> On Fri, 2004-08-20 at 22:59, Jon Smirl wrote:
> > I don't believe the DRM drivers are holding any global kernel locks
> > when they do wait_for_fifo. Any locks held would be internal to DRM and
> > can be changed if needed.
>
> The
On Fri, 2004-08-20 at 22:29, Jon Smirl wrote:
> The delay is very large because this routine is waiting for the
> graphics coprocessor to finish an operation. Some of the operations can
> take many ms to complete; for example telling the chip to copy 64MB of
> memory somewhere. I would think the qu
[please cc me, I'm not on the dri list]
On Fri, 2004-08-20 at 22:29, Jon Smirl wrote:
> The delay is very large because this routine is waiting for the
> graphics coprocessor to finish an operation. Some of the operations can
> take many ms to complete; for example telling the chip to copy 64MB of
On Fri, 2004-08-20 at 22:59, Jon Smirl wrote:
> I don't believe the DRM drivers are holding any global kernel locks
> when they do wait_for_fifo. Any locks held would be internal to DRM and
> can be changed if needed.
There must be a lock. I used to use a patch that I found somewhere (that
does co
On Sat, 2004-08-21 at 09:58, Jon Smirl wrote:
> BTW, loops like this are in most of the DRM drivers for other cards.
> They are probably in accelerated framebuffer drivers too.
I know for a fact that the mga driver also has this problem, and I
suspect that the r128 is also affected (but have not t
* Jon Smirl <[EMAIL PROTECTED]> wrote:
> --- Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > the cleanest and highest performing solution would be to have an
> > interrupt source for 3D completion - do you have such an interrupt
> > handler handy? If yes then you can sleep precisely up to completion:
--- Jon Smirl <[EMAIL PROTECTED]> wrote:
> Michel pointed out that all IOCTL calls hold the big kernel lock.
> Releasing this lock is sure to case problems since the DRM code is not
> designed to be reentrant. I don't know what it will take to fix locking
> to allow this, maybe one of the origina
--- Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Jon Smirl <[EMAIL PROTECTED]> wrote:
>
> > --- Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > > the cleanest and highest performing solution would be to have an
> > > interrupt source for 3D completion - do you have such an interrupt
> > > handler ha
>
> There must be a lock. I used to use a patch that I found somewhere (that
> does conditional reschedules), but it triggers the "scheduling while
> lock held" kernel oops if you enable that option in the kernel
> configuration.
I can't find the lock from a quick code inspection.. I'll add the
re
>
> I can't find the lock from a quick code inspection.. I'll add the
> reschedule to a test drm and I'll build my kernel with all the debugging
> on...
>
I'm running the attached patch to the DRM in CVS on 2.6.8.1 and I'm not
seeing any drm related xruns.. there are other places that can do with
On Mon, Aug 23, 2004 at 12:15:34PM +0100, Dave Airlie wrote:
> @@ -631,7 +631,15 @@
> int slots = ( RADEON_READ( RADEON_RBBM_STATUS )
>& RADEON_RBBM_FIFOCNT_MASK );
> if ( slots >= entries ) return 0;
> -DRM_UDELAY( 1 );
> +
* Dave Airlie <[EMAIL PROTECTED]> wrote:
> int slots = ( RADEON_READ( RADEON_RBBM_STATUS )
> & RADEON_RBBM_FIFOCNT_MASK );
> if ( slots >= entries ) return 0;
> - DRM_UDELAY( 1 );
> +
> + if (need_resched()) {
> +
* Dave Airlie <[EMAIL PROTECTED]> wrote:
> I can't find the lock from a quick code inspection.. I'll add the
> reschedule to a test drm and I'll build my kernel with all the
> debugging on...
there doesnt seem to be any further lock other than the BKL:
0001 0.558ms (+0.000ms): delay_tsc (_
--- Lee Revell <[EMAIL PROTECTED]> wrote:
> On Sun, 2004-08-22 at 22:09, Mike Mestnik wrote:
> > --- Jon Smirl <[EMAIL PROTECTED]> wrote:
> >
> > > Michel pointed out that all IOCTL calls hold the big kernel lock.
> > > Releasing this lock is sure to case problems since the DRM code is
> not
> >
i'll put the patch below into the -P8 patch. (change voluntary_resched()
to cond_resched() if you apply this to a vanilla kernel.)
Ingo
--- linux/drivers/char/drm/drm_os_linux.h.orig
+++ linux/drivers/char/drm/drm_os_linux.h
@@ -14,7 +14,7 @@
#define DRM_ERR(d)
Previously all of the IOCTL calls were protected by the Big Kernel
Lock. If we break that aren't we allowing multiple callers into the
IOCTL code on SMP machines that weren't allowed in before? Doesn't that
mean that we have to check everything to make sure it is SMP safe?
--- Ingo Molnar <[EMAIL
* Jon Smirl <[EMAIL PROTECTED]> wrote:
> Previously all of the IOCTL calls were protected by the Big Kernel
> Lock. If we break that aren't we allowing multiple callers into the
> IOCTL code on SMP machines that weren't allowed in before? Doesn't
> that mean that we have to check everything to ma
--- Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Jon Smirl <[EMAIL PROTECTED]> wrote:
>
> > Previously all of the IOCTL calls were protected by the Big Kernel
> > Lock. If we break that aren't we allowing multiple callers into the
> > IOCTL code on SMP machines that weren't allowed in before? D
* Mike Mestnik <[EMAIL PROTECTED]> wrote:
> > as Alan mentioned it before, the BKL did not protect much, since the DRM
> > code was freely doing copying from and to userspace, and hence dropping
> > the BKL at those places.
> >
> Add sleeping(usleep) to this list, no? The big Q I have is why ar
>
> > Previously all of the IOCTL calls were protected by the Big Kernel
> > Lock. If we break that aren't we allowing multiple callers into the
> > IOCTL code on SMP machines that weren't allowed in before? Doesn't
> > that mean that we have to check everything to make sure it is SMP
> > safe?
>
>
Dave Airlie wrote:
Previously all of the IOCTL calls were protected by the Big Kernel
Lock. If we break that aren't we allowing multiple callers into the
IOCTL code on SMP machines that weren't allowed in before? Doesn't
that mean that we have to check everything to make sure it is SMP
safe?
as Ala
On Sun, 2004-08-22 at 22:09, Mike Mestnik wrote:
> --- Jon Smirl <[EMAIL PROTECTED]> wrote:
>
> > Michel pointed out that all IOCTL calls hold the big kernel lock.
> > Releasing this lock is sure to case problems since the DRM code is not
> > designed to be reentrant. I don't know what it will tak
On Mon, 2004-08-23 at 11:43, Fernando Pablo Lopez-Lezcano wrote:
> On Mon, 2004-08-23 at 11:30, Ingo Molnar wrote:
> > i'll put the patch below into the -P8 patch. (change voluntary_resched()
> > to cond_resched() if you apply this to a vanilla kernel.)
>
> I'll start a kernel build to test this o
On Mon, 2004-08-23 at 11:30, Ingo Molnar wrote:
> i'll put the patch below into the -P8 patch. (change voluntary_resched()
> to cond_resched() if you apply this to a vanilla kernel.)
I'll start a kernel build to test this on top of P7... (I was about to
ask "what about the other places in radeon_c
--- Fernando Pablo Lopez-Lezcano <[EMAIL PROTECTED]> wrote:
> On Mon, 2004-08-23 at 11:43, Fernando Pablo Lopez-Lezcano wrote:
> > On Mon, 2004-08-23 at 11:30, Ingo Molnar wrote:
> > > i'll put the patch below into the -P8 patch. (change
> voluntary_resched()
> > > to cond_resched() if you apply t
On Tue, 2004-08-24 at 22:51, Jon Smirl wrote:
> --- Fernando Pablo Lopez-Lezcano <[EMAIL PROTECTED]> wrote:
> > On Mon, 2004-08-23 at 11:43, Fernando Pablo Lopez-Lezcano wrote:
> > > On Mon, 2004-08-23 at 11:30, Ingo Molnar wrote:
> > > > i'll put the patch below into the -P8 patch. (change volunta
I guess I don't understand, the article said the sound(OSS) took the BKL?
It didn't say that ALSA's OSS is effected, I'm assuming that it is not.
In any case ALSA still uses ioctls. So no mater what sound takes the BKL
and disables preemption?
I don't think that preemption could work at all, un
On Fri, 2004-08-27 at 13:23, Mike Mestnik wrote:
> I guess I don't understand, the article said the sound(OSS) took the BKL?
> It didn't say that ALSA's OSS is effected, I'm assuming that it is not.
> In any case ALSA still uses ioctls. So no mater what sound takes the BKL
> and disables preempt
* Fernando Pablo Lopez-Lezcano <[EMAIL PROTECTED]> wrote:
> Once I boot I can get, for example, two instances of glxgears happily
> going on at once. But if I start jack with realtime priority from
> within qjackctl I get a hard lock very soon, the machine does not even
> react to the sysrq magic
42 matches
Mail list logo
