[lkml]   [2000]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
> 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
>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:

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:

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)

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 !


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:56    [W:0.026 / U:8.684 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site