From: Lee R. <rlr...@jo...> - 2004-08-20 23:46:39
|
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: pcmC0D0p > [<f8ff9b8f>] snd_pcm_period_elapsed+0x36f/0x560 [snd_pcm] > [<c011eec7>] scheduler_tick+0x2b7/0x580 > [<f88e4fe4>] ehci_irq+0xe4/0x300 [ehci_hcd] > [<f90e1891>] snd_ice1712_interrupt+0x171/0x1e0 [snd_ice1712] > [<c012b2c0>] generic_handle_IRQ_event+0x30/0x60 > [<c0108506>] do_IRQ+0x146/0x3b0 > [<c0106a88>] common_interrupt+0x18/0x20 > [<c01157b8>] delay_pmtmr+0x18/0x20 > [<c0215579>] __delay+0x9/0x10 > [<f88f3aa3>] radeon_do_wait_for_fifo+0x43/0x60 [radeon] > [<f88f3ad2>] radeon_do_wait_for_idle+0x12/0x60 [radeon] > [<f88eefec>] radeon_ioctl+0xbc/0x150 [radeon] > [<f88f5290>] radeon_cp_idle+0x0/0xa0 [radeon] > [<c01968de>] sys_ioctl+0x21e/0x3d0 > [<c01068c9>] sysenter_past_esp+0x52/0x71 > 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 100000 /* 100 ms */ The driver does not seem to have a default for this, so you need to find the userspace code that is initializing the DRI and find the value it is being set to. Why is this allowed to be so large? Lee |
From: Dave A. <ai...@li...> - 2004-08-21 05:37:39
|
> > 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 100000 /* 100 ms */ > > The driver does not seem to have a default for this, so you need to find > the userspace code that is initializing the DRI and find the value it is > being set to. > the current default is 10000 usecs from radeon_dri.h in xc/programs/Xserver/hw/xfree86/drivers/ati (Xorg tree) you can use the option CPusecTimeout in your /etc/X11/xorg.conf file to tweak this value .. Previous investigations have found getting the 3D card and soundcard to balance latencies is difficult :-), I think the DRM could do with a bit of profiling on what the average times it takes for the GPU to become idle.. Dave. > Why is this allowed to be so large? > > Lee > > > > ------------------------------------------------------- > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > -- > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel > -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person |
From: Lee R. <rlr...@jo...> - 2004-08-21 05:49:50
|
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:#define RADEON_MAX_USEC_TIMEOUT 100000 /* 100 ms */ > > > > The driver does not seem to have a default for this, so you need to find > > the userspace code that is initializing the DRI and find the value it is > > being set to. > > > the current default is 10000 usecs from radeon_dri.h in > xc/programs/Xserver/hw/xfree86/drivers/ati (Xorg tree) you can use the > option CPusecTimeout in your /etc/X11/xorg.conf file to tweak this value > .. What happens if it times out? We drop a few frames? > > Previous investigations have found getting the 3D card and soundcard to > balance latencies is difficult :-) We are actually not interested in balancing latencies. What is needed is a way to tell the system that audio latency is important, 3D is not. > , I think the DRM could do with a bit of > profiling on what the average times it takes for the GPU to become idle.. > Indeed. For the radeon driver it looks like you could just measure the number of times you spin in those loops. Or, just keep setting it lower and see if it breaks. Lee |
From: Fernando P. Lopez-L. <na...@cc...> - 2004-08-22 22:43:47
|
On Fri, 2004-08-20 at 22: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:#define RADEON_MAX_USEC_TIMEOUT 100000 /* 100 ms */ > > > > The driver does not seem to have a default for this, so you need to find > > the userspace code that is initializing the DRI and find the value it is > > being set to. > > > the current default is 10000 usecs from radeon_dri.h in > xc/programs/Xserver/hw/xfree86/drivers/ati (Xorg tree) you can use the > option CPusecTimeout in your /etc/X11/xorg.conf file to tweak this value Hey, thanks, I was not aware of that option! Changing the value has the predictable effect of lowering the duration of the latency hits I get. Setting it to "1000" (instead of "10000") makes it possible to run glxgears (the test I'm using to trigger xruns) with bigger screen sizes than before. I can still trigger xruns, of course, but they are < 1ms instead of < 10ms :-( DRI gurus: let me know if somebody comes up with a patch, I'm willing to be a guinea pig... -- Fernando |
From: Jon S. <jon...@ya...> - 2004-08-21 05:29:33
|
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 killing both audio and video latency. The problem here is that most graphics commands are very short in duration. Some of these commands can be issued a million of times per second. A few commands are much longer running. I don't believe there is an easy way to tell how long the commands will run. 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. What's the right way to write a loop like this that meets the above requirements and also satisfies the audio needs? static int radeon_do_wait_for_idle( drm_radeon_private_t *dev_priv ) { int i, ret; dev_priv->stats.boxes |= RADEON_BOX_WAIT_IDLE; ret = radeon_do_wait_for_fifo( dev_priv, 64 ); if ( ret ) return ret; for ( i = 0 ; i < dev_priv->usec_timeout ; i++ ) { if ( !(RADEON_READ( RADEON_RBBM_STATUS ) & RADEON_RBBM_ACTIVE) ) { radeon_do_pixcache_flush( dev_priv ); return 0; } DRM_UDELAY( 1 ); } #if RADEON_FIFO_DEBUG DRM_ERROR( "failed!\n" ); radeon_status( dev_priv ); #endif return DRM_ERR(EBUSY); } ===== Jon Smirl jon...@ya... __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail |
From: Ingo M. <mi...@el...> - 2004-08-21 09:02:40
|
* Jon Smirl <jon...@ya...> 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 just fine as long as you stay preemptible. Also, if need_resched() is true then you should get out of your locks ASAP. the _ability_ to preempt quickly should not affect 3D performance in any noticeable way: if the only app running is a 3D app, or it has a high priority (because the user wants good 3D performance) then it will perform just fine. Conversely, if an audio app has high priority then it must see low latencies. So this is not an act of balancing, this is an act of _enabling_ low latencies. Looping in the kernel for even 1 msec while holding locks is very, very bad and should be avoided at every cost. In fact you should shoot for as quick preemptability as possible whenever you are looping for 3D completion, because your code is not doing anything productive in fact. 'quick preemptability' != scheduling away, it only means 'scheduling away if need_resched() is set'. > What's the right way to write a loop like this that meets the above > requirements and also satisfies the audio needs? > for ( i = 0 ; i < dev_priv->usec_timeout ; i++ ) { > if ( !(RADEON_READ( RADEON_RBBM_STATUS ) > & RADEON_RBBM_ACTIVE) ) { > radeon_do_pixcache_flush( dev_priv ); > return 0; > } > DRM_UDELAY( 1 ); add: if (need_resched()) { break locks ... cond_resched(); reacquire locks ... } and make sure the breaking of the locks is safe at that point (no other 3D application should be able to interfere with your polling, etc.). this will solve all the audio complaints. as a bonus, if you want to be 'nice' to lower prio processes as well, you can also do: if ((i & 127) == 127) { drop locks ... msleep(1); reqacquire locks ... } this will busy-loop up to 127 usecs, and will sleep for 1 msec afterwards. 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: if ((i & 127) == 127) { drop locks ... wait_event(&driver->wait_queue, RADEON_READ(RADEON_RBBM_STATUS)); reqacquire locks ... break; } and in the IRQ handler, do a: wake_up(&driver->wait_queue); the wakeup doesnt even have to be precise - i.e. you can wake up early or for all events - wait_event()'s second field, the 'is the wait done' takes care of it and re-suspends the task if the 3D engine is still busy. (to implement a timeout and signal-awareness as well you can use wait_event_interruptible_timeout().) Ingo |
From: Jon S. <jon...@ya...> - 2004-08-21 16:58:41
|
--- Ingo Molnar <mi...@el...> 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 would generate millions of them per second. This is the same problem network cards have, you can interrupt the machine to death. I would expect the best solution is to make a few passes through the loop delaying a couple usec to catch the common case of quick completion. Then switch to doing need_resched(). I haven't tried tuning this code before, other people like Michel Dänzer may have more experience in this area and know the history of the previous attempts. Someone who knows the details of DRM locking needs to do the changes. BTW, loops like this are in most of the DRM drivers for other cards. They are probably in accelerated framebuffer drivers too. ===== Jon Smirl jon...@ya... _______________________________ Do you Yahoo!? Express yourself with Y! Messenger! Free. Download now. http://messenger.yahoo.com |
From: Fernando P. Lopez-L. <na...@cc...> - 2004-08-21 19:36:01
|
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 tested it). When I looked at them a while ago the code base seemed very similar so that most probably a fix for one of them would be usable for the others. -- Fernando |
From: Ingo M. <mi...@el...> - 2004-08-22 17:50:50
|
* Jon Smirl <jon...@ya...> wrote: > --- Ingo Molnar <mi...@el...> 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 would generate > millions of them per second. This is the same problem network cards > have, you can interrupt the machine to death. you'd only have to enable interrupt generation when you are not busy-polling. In 99.9% of the cases (when !need_resched()) you could busy poll as much as you want, and keep IRQ generation off. Very likely IRQ generation can be turned on/off via a single PCI write on most 3D hardware. Anyway, IRQ generation would just be a 'nice' thing. But the following property is a must: > I would expect the best solution is to make a few passes through the > loop delaying a couple usec to catch the common case of quick > completion. Then switch to doing need_resched(). no. If need_resched() is set then the code *must* try to schedule ASAP. There is no excuse for not doing so - 'performance will suffer' is not a correct argument becase _if_ need_resched() is true then the system (and the user) doesnt want the 3D app to run right now. There will be no performance difference to the 3D app, since by having high latencies the DRI code does not give any extra performance to 3D apps, it only increases the scheduling latency! The timeslices of the 3D app are used up depending on how long the 3D app runs - so if it burns cycles busy-polling it will in fact get less CPU time on average. (if the CPU is contended.) Anyway, need_resched() set is not a common condition, and if it happens then kernel code _must_ react. (In fact most kernel code will be preempted right away - but the DRI code runs under spinlocks.) So the correct solution is to add something like this to _at least_ the busy-polling code: if (need_resched()) { ... drop locks ... cond_resched(); ... reacquire locks ... } or, if there's a single spinlock held (the BKL doesnt count) then: cond_resched_lock(&driver->lock); (but the locking obviously has to be correct and safe.) ok? Ingo |
From: Mike M. <che...@ya...> - 2004-08-23 02:19:42
|
--- Ingo Molnar <mi...@el...> wrote: > > * Jon Smirl <jon...@ya...> wrote: > > > --- Ingo Molnar <mi...@el...> 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 would generate > > millions of them per second. This is the same problem network cards > > have, you can interrupt the machine to death. > > you'd only have to enable interrupt generation when you are not > busy-polling. In 99.9% of the cases (when !need_resched()) you could > busy poll as much as you want, and keep IRQ generation off. Very likely > IRQ generation can be turned on/off via a single PCI write on most 3D > hardware. Anyway, IRQ generation would just be a 'nice' thing. But the > following property is a must: > This lookes like a great idea. We turn on interrupt generation just after we drop our spinlock(in the if need_resched() block). This would greatly improve system proformance as IRQs would only be used when we wait for long periods. > > I would expect the best solution is to make a few passes through the > > loop delaying a couple usec to catch the common case of quick > > completion. Then switch to doing need_resched(). > > no. If need_resched() is set then the code *must* try to schedule ASAP. > There is no excuse for not doing so - 'performance will suffer' is not a > correct argument becase _if_ need_resched() is true then the system (and > the user) doesnt want the 3D app to run right now. There will be no > performance difference to the 3D app, since by having high latencies the > DRI code does not give any extra performance to 3D apps, it only > increases the scheduling latency! The timeslices of the 3D app are used > up depending on how long the 3D app runs - so if it burns cycles > busy-polling it will in fact get less CPU time on average. (if the CPU > is contended.) > I see jerky ness alot with Q3, where frame rate spikes for one frame. This lookes like a good explination, as the frame b4 and after would have many of the same GL calls. End Of Line. > Anyway, need_resched() set is not a common condition, and if it happens > then kernel code _must_ react. (In fact most kernel code will be > preempted right away - but the DRI code runs under spinlocks.) > > So the correct solution is to add something like this to _at least_ the > busy-polling code: > > if (need_resched()) { > ... drop locks ... > cond_resched(); > ... reacquire locks ... > } > > or, if there's a single spinlock held (the BKL doesnt count) then: > > cond_resched_lock(&driver->lock); > > (but the locking obviously has to be correct and safe.) > > ok? > > Ingo > > > ------------------------------------------------------- > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > -- > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel > __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail |
From: Lee R. <rlr...@jo...> - 2004-08-21 05:35:59
|
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 |
From: Jon S. <jon...@ya...> - 2004-08-21 05:59:03
|
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 <rlr...@jo...> wrote: > 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 > > ===== Jon Smirl jon...@ya... __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail |
From: Michel <mi...@da...> - 2004-08-21 14:27:28
|
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. --=20 Earthling Michel D=C3=A4nzer | Debian (powerpc), X and DRI develop= er Libre software enthusiast | http://svcs.affero.net/rm.php?r=3Ddaenzer |
From: Dave A. <ai...@li...> - 2004-08-21 15:15:36
|
> > 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 done via ioctls.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person |
From: Alan C. <al...@lx...> - 2004-08-22 11:25:33
|
On Sad, 2004-08-21 at 16:00, Michel D=C3=A4nzer 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. >=20 > Keep in mind that any ioctl function runs with the Big Kernel Lock held. The BKL is dropped whenever you sleep and retaken on resume anyway. That isn't a problem. Putting a need_resched() test in the loop will get you "fair" behaviour and in the single gaming app case won't generally trigger anyway. Alan |
From: Fernando P. Lopez-L. <na...@cc...> - 2004-08-21 19:25:42
|
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 conditional reschedules), but it triggers the "scheduling while lock held" kernel oops if you enable that option in the kernel configuration. -- Fernando > --- Lee Revell <rlr...@jo...> wrote: > > > 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 > > > > > > > ===== > Jon Smirl > jon...@ya... > > > > __________________________________ > Do you Yahoo!? > Yahoo! Mail Address AutoComplete - You start. We finish. > http://promotions.yahoo.com/new_mail |
From: Jon S. <jon...@ya...> - 2004-08-22 01:51:46
|
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. Until locking is adjusted we can't add the schedule call. --- Fernando Pablo Lopez-Lezcano <na...@cc...> 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. > > 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. > > -- Fernando > > > --- Lee Revell <rlr...@jo...> wrote: > > > > > 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 > > > > > > > > > > > > ===== > > Jon Smirl > > jon...@ya... > > > > > > > > __________________________________ > > Do you Yahoo!? > > Yahoo! Mail Address AutoComplete - You start. We finish. > > http://promotions.yahoo.com/new_mail > > ===== Jon Smirl jon...@ya... __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail |
From: Alan C. <al...@lx...> - 2004-08-22 11:26:16
|
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 broken then its already broken and it doesn't matter. If it isnt broken then its still not broken |
From: Mike M. <che...@ya...> - 2004-08-23 02:09:57
|
--- Jon Smirl <jon...@ya...> 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 original DRM authors will pop in here > with the answer. Until locking is adjusted we can't add the schedule > call. > From what I'v read, http://lwn.net/Articles/86859/, it's not a global kernel lock (I.E. it dosen't stop non-locked kernel code from running). So the only reason it effects audio performace is that well, read the article :) Also DRI allready runes with it off in ioctls, every time there is a sleep. This is why DRI has spinlocks, right? Now if we turn BKL off for our ioctls we defeat the pupose it was turned on for, what is that? Would it be posible to use differed execution instead of blindly droping the BKL? As for the other DRI-spinlocks the code presented by Ingo Molnar lookes correct, no arguments here. I just don't see why DRI needs to drop the BKL any sooner then any other part of the kernel? After all DRI dosen't request it, it's just one of many victums of the ioctl BKL. So I think it would be best to let upstream fix the DRI BKL problem. > --- Fernando Pablo Lopez-Lezcano <na...@cc...> 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. > > > > 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. > > > > -- Fernando > > > > > --- Lee Revell <rlr...@jo...> wrote: > > > > > > > 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 > > > > > > > > > > > > > > > > > ===== > > > Jon Smirl > > > jon...@ya... > > > > > > > > > > > > __________________________________ > > > Do you Yahoo!? > > > Yahoo! Mail Address AutoComplete - You start. We finish. > > > http://promotions.yahoo.com/new_mail > > > > > > > ===== > Jon Smirl > jon...@ya... > > > > __________________________________ > Do you Yahoo!? > Yahoo! Mail - 50x more storage than other providers! > http://promotions.yahoo.com/new_mail > > > ------------------------------------------------------- > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > -- > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel > __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail |
From: Lee R. <rlr...@jo...> - 2004-08-23 02:42:12
|
On Sun, 2004-08-22 at 22:09, Mike Mestnik wrote: > --- Jon Smirl <jon...@ya...> 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 original DRM authors will pop in here > > with the answer. Until locking is adjusted we can't add the schedule > > call. > > > >From what I'v read, http://lwn.net/Articles/86859/, it's not a global > kernel lock (I.E. it dosen't stop non-locked kernel code from running). > So the only reason it effects audio performace is that well, read the > article :) > The reason the BKL affects audio performance is that taking the BKL disables preemption. Lee |
From: Mike M. <che...@ya...> - 2004-08-23 17:42:55
|
--- Lee Revell <rlr...@jo...> wrote: > On Sun, 2004-08-22 at 22:09, Mike Mestnik wrote: > > --- Jon Smirl <jon...@ya...> 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 original DRM authors will pop in > here > > > with the answer. Until locking is adjusted we can't add the schedule > > > call. > > > > > >From what I'v read, http://lwn.net/Articles/86859/, it's not a global > > kernel lock (I.E. it dosen't stop non-locked kernel code from > running). > > So the only reason it effects audio performace is that well, read the > > article :) > > > > The reason the BKL affects audio performance is that taking the BKL > disables preemption. > But ONLY while your not sleeping. > Lee > > __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail |
From: Mike M. <che...@ya...> - 2004-08-27 17:23:13
|
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, unless when the BKL is [1]droped you preemptate. I think you have something wrong, as DRI dose these things alot so it might not block preemption. 1. msleep, usercpy, ect. --- Lee Revell <rlr...@jo...> wrote: > On Sun, 2004-08-22 at 22:09, Mike Mestnik wrote: > > --- Jon Smirl <jon...@ya...> 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 original DRM authors will pop in > here > > > with the answer. Until locking is adjusted we can't add the schedule > > > call. > > > > > >From what I'v read, http://lwn.net/Articles/86859/, it's not a global > > kernel lock (I.E. it dosen't stop non-locked kernel code from > running). > > So the only reason it effects audio performace is that well, read the > > article :) > > > > The reason the BKL affects audio performance is that taking the BKL > disables preemption. > > Lee > > > > ------------------------------------------------------- > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > -- > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel > __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail |
From: Lee R. <rlr...@jo...> - 2004-08-27 17:44:48
|
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 preemption? > > I don't think that preemption could work at all, unless when the BKL is > [1]droped you preemptate. I think you have something wrong, as DRI dose > these things alot so it might not block preemption. > > 1. msleep, usercpy, ect. > The article actually didn't say much about why the BKL affects audio performance. Sound (meaning ALSA) does not take the BKL. When another process takes the BKL, however, preemption is disabled until that process either drops the BKL or goes to sleep. So to minimize audio latency (which is just the amount of time between when a SCHED_FIFO process is made runnable and when it gets the processor), other parts of the kernel need to minimize the amount of time they spend non-preemptible (holding the BKL or a spinlock, or having explicityly disabled preemption). Therefore ioctl is bad and should be avoided wherever possible. It's not a big deal for ALSA, because the ioctls complete very quickly, and they only happen when starting or stopping the audio device anyway. But if we are recording audio and the DRI comes along and spends more than a few hundred usecs in an ioctl(), we are screwed. Like Ingo said, the real fix is to replace the DRM's use of the BKL with fine grained locking. Also please don't top post! Lee |
From: Lee R. <rlr...@jo...> - 2004-08-21 19:49:42
|
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. > > 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. > There are several, and they undoubtedly interact in subtle ways. Grep for spin_lock in the drm directory and you will see what i mean. These locks are internal to the DRM and not global kernel locks, which makes it possible to fix them, but holding any spinlock will disable preemption. Based on the generalized solution Ingo proposed and the reaction of the DRI developers it seems like this will not be too hard to fix, but a thorough understanding of the locking code will be required. Lee |
From: Dave A. <ai...@li...> - 2004-08-23 10:22:47
|
> > 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 reschedule to a test drm and I'll build my kernel with all the debugging on... Dave. > > > --- Lee Revell <rlr...@jo...> wrote: > > > > > 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 > > > > > > > > > > > > ===== > > Jon Smirl > > jon...@ya... > > > > > > > > __________________________________ > > Do you Yahoo!? > > Yahoo! Mail Address AutoComplete - You start. We finish. > > http://promotions.yahoo.com/new_mail > > > > ------------------------------------------------------- > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > -- > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel > -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person |