On Thu, 15 Jan 2015 17:16:34 -0800 Andrew Morton <a...@linux-foundation.org> wrote:
> > I saw roughly 5% win in a fast-path loop over kmem_cache_alloc/free > > in CONFIG_PREEMPT. (14.821 ns -> 14.049 ns) > > I'm surprised. preempt_disable/enable are pretty fast. I wonder why > this makes a measurable difference. Perhaps preempt_enable()'s call > to preempt_schedule() added pain? profiling function tracing I discovered that accessing preempt_count was actually quite expensive, even just to read. But it may not be as bad since Peter Zijlstra converted preempt_count to a per_cpu variable. Although, IIRC, the perf profiling showed the access to the %gs register was where the time consuming was happening, which is what I believe per_cpu variables still use. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
