Hello, On Thu, Apr 14, 2011 at 04:10:34PM -0500, Christoph Lameter wrote: > On Thu, 14 Apr 2011, Eric Dumazet wrote: > > > Not sure its a win for my servers, where CONFIG_PREEMPT_NONE=y > > Well the fast path would then also be irq safe. Does that bring us > anything? > > We could not do the cmpxchg in the !PREEMPT case and instead simply store > the value. > > The preempt on/off seems to be a bigger deal for realtime. Also, the cmpxchg used is local one w/o LOCK prefix. It might not bring anything to table on !PREEMPT kernels but at the same time it shouldn't hurt either. One way or the other, some benchmark numbers showing that it at least doesn't hurt would be nice. > > Maybe use here latest cmpxchg16b stuff instead and get rid of spinlock ? > > Shaohua already got an atomic in there. You mean get rid of his preempt > disable/enable in the slow path? I personally care much less about slow path. According to Shaohua, atomic64_t behaves pretty nice and it isn't too complex, so I'd like to stick with that unless complex this_cpu ops can deliver something much better. Thanks. -- tejun -- 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 internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>