Skip to contentSkip to conversation

lockmeter for x86_64

PATCH In review Alexander Nyberg 2 participants 2 messages Aug 22, 2004 – Aug 23, 2004

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 lockmeter for x86_64

This is basically a cut and paste from i386 code.
At some places however some unresolved addresses at places like [0x1000211eb38] shows up, which is a bit weird. I'm hoping for a comment from any of the SGI guys, as the code is so similar to i386 I don't know if problem lies below or in the generic code.

Against 2.6.8.1-mm2, but should apply against just about any -mm

arch/x86_64/lib/dec_and_lock.c renamed from arch/x86_64/lib/dec_and_lock.c_orig +2 -0
@@ -10,6 +10,7 @@
 #include <linux/spinlock.h>
 #include <asm/atomic.h>
 
+#ifndef ATOMIC_DEC_AND_LOCK
 int atomic_dec_and_lock(atomic_t *atomic, spinlock_t *lock)
 {
 	int counter;
@@ -38,3 +39,4 @@ slow_path:
 	spin_unlock(lock);
 	return 0;
 }
+#endif
include/asm-x86_64/lockmeter.h new file +102 -0

102 lines not on this page · raw message

arch/x86_64/Kconfig.debug renamed from arch/x86_64/Kconfig.debug_orig +7 -0
@@ -62,6 +62,13 @@ config IOMMU_LEAK
          Add a simple leak tracer to the IOMMU code. This is useful when you
 	 are debugging a buggy device driver that leaks IOMMU mappings.
 
+config LOCKMETER
+	bool "Kernel lock metering"
+	depends on SMP
+	help
+	  Say Y to enable kernel lock metering, which adds overhead to SMP locks,
+	  but allows you to see various statistics using the lockstat command.
+
 source "arch/x86_64/Kconfig.kgdb"
 
 endmenu
include/asm-x86_64/spinlock.h renamed from include/asm-x86_64/spinlock.h_orig +69 -0

90 lines not on this page · raw message

#1 lore raw
Quoted 8 lines · Alexander Nyberg

This is basically a cut and paste from i386 code.
At some places however some unresolved addresses at places like [0x1000211eb38] shows up, which is a bit weird. I'm hoping for a comment from any of the SGI guys, as the code is so similar to i386 I don't know if problem lies below or in the generic code.

Against 2.6.8.1-mm2, but should apply against just about any -mm

Thanks - I'll add it to -mm.

If you want the SGI developers to pay attention to it, you'd better Cc them. One never knows how closely individuals monitor this list.