On Mon, 28 Jul 2008, James Bottomley wrote: > > Sorry ... should have been clearer. My main concern is the cost of > barrier() which is just a memory clobber ... we have to use barriers to > place the probe points correctly in the code. Oh, "barrier()" itself has _much_ less cost. It still has all the "needs to flush any global/address-taken-of variables to memory" property and can thus cause reloads, but that's kind of the point of it, after all. So in that sense "barrier()" is free: the only cost of a barrier is the cost of what you actually need to get done. It's not really "free", but it's also not any more costly than what your objective was. In contrast, the "objective" in an empty function call is seldom the serialization, so in that case the serialization is all just unnecessary overhead. Also, barrier() avoids the big hit of turning a leaf function into a non-leaf one. It also avoids all the fixed registers and the register clobbers (although for tracing purposes you may end up setting up fixed regs, of course). The leaf -> non-leaf thing is actually often the major thing. Yes, the compiler will often inline functions that are simple enough to be leaf functions with no stack frame, so we don't have _that_ many of them, but when it hits, it's often the most noticeable part of an unnecessary function call. And "barrier()" should never trigger that problem. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
