On 06/29/2013 04:23 PM, Waiman Long wrote:
On 06/29/2013 01:45 PM, Linus Torvalds wrote:
But more importantly, I think this needs to be architecture-specific,
and using<linux/spinlock_refcount.h> to try to do some generic 64-bit
cmpxchg() version is a bad bad idea.
Yes, I can put the current implementation into
asm-generic/spinlock_refcount.h. Now I need to put an
asm/spinlock_refcount.h into every arch's include/asm directory.
Right? I don't think there is a mechanism in the build script to
create a symlink from asm to generic-asm when a header file is
missing. Is it the general rule that we should have a
linux/spinlock_refcount.h that include asm/spinlock_refcount.h instead
of including asm/spinlock_refcount.h directly?
We have several architectures coming up that have memory transaction
support, and the "spinlock with refcount" is a perfect candidate for a
transactional memory implementation. So when introducing a new atomic
like this that is very performance-critical and used for some very
core code, I really think architectures would want to make their own
optimized versions.
These things should also not be inlined, I think.
I think I got it now. For architecture with transactional memory support
to use an alternative implementation, we will need to use some kind of
dynamic patching at kernel boot up time as not all CPUs in that
architecture will have that support. In that case the helper functions
have to be real functions and cannot be inlined. That means I need to
put the implementation into a spinlock_refcount.c file with the header
file contains structure definitions and function prototypes only. Is
that what you are looking for?
Regards,
Longman
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
