On Tuesday 23 December 2008 05:13:28 Mathieu Desnoyers wrote: > > I can be convinced, but I'll need more than speculation. Assuming > > local_long_atomic_t, can you produce a patch which uses it somewhere else? > > I had this patch applying over Christoph Lameter's vm tree last > February. It did accelerate the slub fastpath allocator by using > cmpxchg_local rather than disabling interrupts. cmpxchg_local is not > using the local_t type, but behaves similarly to local_cmpxchg. > > http://lkml.org/lkml/2008/2/28/568 OK, I'll buy that. So we split local_t into a counter and an atomic type. > I know that > local_counter_long_t and local_atomic_long_t are painful to write, but > that would follow the current atomic_t vs atomic_long_t semantics. Hm ? OK, I've looked at how they're used, to try to figure out whether long is the right thing. Counters generally want to be long, but I was in doubt about atomics; yet grep shows that atomic_long_t is quite popular. Then I hit struct nfs_iostats which would want a u64 and a long. I don't think we want local_counter_u64 etc. Just thinking out loud, perhaps a new *type* is the wrong direction? How about a set of macros which take a fundamental type, such as: DECLARE_LOCAL_COUNTER(type, name); local_counter_inc(type, addr); ... DECLARE_LOCAL_ATOMIC(type, name); local_atomic_add_return(type, addr); This allows pointers, u32, u64, long, etc. If a 32-bit arch can't do 64-bit local_counter_inc easily, at least the hairy 64-bit code can be eliminated at compile time. Or maybe that's overdesign? Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|