Le vendredi 19 novembre 2010 Ã 11:59 -0600, Christoph Lameter a Ãcrit : > On Fri, 19 Nov 2010, Christoph Lameter wrote: > > > Ok so rename the macros to this_cpu_return_inc/dec/add/sub? > > Actually this is fetchadd. So call I will call this this_cpu_fetch_add/inc/dec/sub. > It doesnt really matter, because the final "res += added_value" can be optimized out by compiler if needed, since its C code. For example in net/core/neighbour.c, function neigh_alloc() we do entries = atomic_inc_return(&tbl->entries) - 1; if (entries >= tbl->gc_thresh3 || This generates this optimal code : mov $0x1,%eax lock xadd %eax,0x1d0(%rdi) cmp 0xdc(%rdi),%eax Yes, if we had atomic_fetch_inc() this could be written : entries = atomic_fetch_inc(&tbl->entries); if (entries >= tbl->gc_thresh3 || Not sure its clearer in this form. Is it worth adding another seldom used API ? Everybody understand the xxxx_inc_return() idiom -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>