lkml.org 
[lkml]   [2004]   [Dec]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6
Esben Nielsen wrote:

> Muteces are also an overhead. There must be a lot of locks in the system
> which can safely be transfered back to raw spinlocks as the locking time
> is in the same order of the locking time internally in a mutex. There is
> no perpose of using a mutex instead of a raw spinlock if the region being
> locked is shorter or about the same as the job of handling the mutex
> internals and rescheduling (twice)!

That will certainly be the case in some scenarios. It seems
useful for the mutex user to have a means to advice of the
anticipated usage (hold time).

The other [perhaps additional] means of adaptation would be
Solaris-style where a failed mutex acquisition attempt would
spin rather than block the caller if the mutex owner is
currently running on some other cpu. The rationale being the
spin wait time is less overhead compared with two context
switches. Though I'd expect this ideal has been batted around
here before.

-john

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

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.054 / U:1.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site