> 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/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:25 EST