Messages in this thread | | | From | Benno Senoner <> | Date | Sun, 20 Feb 2000 16:12:57 +0100 |
| |
> Dave Miller wrote: >> A lock can be held for 2 minutes at a time, this isn't what matters. >>
Roger Larsson wrote: >It does matter. >Since all the time you are holding the lock you remain in kernel. >All the time you remain in kernel prevents schedules, even if an >interrupt >awakes a process with higher priority. >To get working multimedia (like audio) any code executing in kernel for >more than a few microseconds may give you problems. > >Ingo Molnar has prepared some patches that helps. (Nothing released >for 2.3 yet) > >For the more about this story check: > http://www.gardena.net/benno/linux/audio > >/RogerL
What routines in particular are affected by these long spinlocks holds ?
My latencytests showed that Ingos patches (lowlatency-N6B) for the 2.2.10 kernel
using a process doing:
while(1) { write() to /dev/dsp }
provides rock solid timing: the time it takes to execute the write call is affected by a jitter of max 0.5ms - 1ms.
As far I know Ingo did not change the spinlock behavoiur, but only checked for the need of rescheduling in critical routines (disk layer, buffercache etc) more often.
I am really interested in which case the spinlocks could give us problems. ( ie userspace application freezes several msecs because of some spinlocks held by some kernel routines)
PS: Manfred have you tried to run your spinlocks tests on lowlatency-2.2.10-N6B ? Don't forget do run all your EIDE disks including the ATAPI CDROM in DMA mode with unmask-irq ? hdparm -d 1 -c 1 -u 1 /dev/hd*
If I don't tune the EIDE devices, I can only achieve 10-15ms latencies in my tests instead of 2-3ms using DMA !
Let us know !
Benno.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |