On Thu, Mar 21, 2013 at 09:35:46AM -0700, Kent Overstreet wrote: > So, for sticking kiocb completions on the kioctx ringbuffer, we need a > lock - it unfortunately can't be lockless. > > When the kioctx is shared between threads on different cpus and the rate > of completions is high, this lock sees quite a bit of contention - in > terms of cacheline contention it's the hottest thing in the aio subsystem. > > That means, with a regular spinlock, we're going to take a cache miss to > grab the lock, then another cache miss when we touch the data the lock > protects - if it's on the same cacheline as the lock, other cpus spinning > on the lock are going to be pulling it out from under us as we're using > it. > > So, we use an old trick to get rid of this second forced cache miss - make > the data the lock protects be the lock itself, so we grab them both at > once.
Reviewed-by: "Theodore Ts'o" <ty...@mit.edu> -- 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/
