lkml.org 
[lkml]   [2006]   [Aug]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 2/8] Implement always-locked bit ops, for memory shared with an SMP hypervisor.
Christoph Lameter wrote:
> Thats a good goal but what about the rest of us who have to maintain
> additional forms of bit operations for all architectures. How much is this
> burden? Are locked atomic bitops really that more expensive?
>

It needn't be all architectures yet - only architectures that want to
compile Xen drivers are really affected. Perhaps a better place for
these locking primitives is in a Xen-specific driver header which
defines appropriate primitives for the architectures required? Last I
remember, there were still some issues here where atomic partial word
operations couldn't be supported on some architectures.

To answer your question, yes. On most i386 cores, locks destroy
performance, and even unintentional use of a single locked operation in
a critical path, on uncontended local memory, can have several hundred
cycles downstream penalty. I accidentally used one once during context
switch, and saw a 30% reduction in switch performance - on a modern
processor.

Zach
-
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: 2006-08-03 03:21    [W:0.095 / U:0.292 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site