lkml.org 
[lkml]   [2001]   [Jan]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] 2.4.0-prerelease: preemptive kernel.
On Thu, Jan 04, 2001 at 01:39:57PM -0800, Nigel Gamble wrote:
> Experience has shown that adaptive spinlocks are not worth the extra
> overhead (if you mean the type that spin for a short time
> and then decide to sleep). It is better to use spin_lock_irqsave()
> (which, by definition, disables kernel preemption without the need
> to set a no-preempt flag) to protect regions where the lock is held
> for a maximum of around 100us, and to use a sleeping mutex lock for
> longer regions. This is what I'm working towards.

What experience ? Only real-time latency testing or SMP scalability
testing?

The case I was thinking about is a heavily contended lock like the
inode semaphore of a file that is used by several threads on several
CPUs in parallel or the mm semaphore of a often faulted shared mm.

It's not an option to convert them to a spinlock, but often the delays
are short enough that a short spin could make sense.

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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