Messages in this thread | | | Date | Fri, 7 May 2004 21:59:06 +0200 | From | Andrea Arcangeli <> | Subject | Re: RCU scaling on large systems |
| |
On Fri, May 07, 2004 at 11:17:06AM -0700, William Lee Irwin III wrote: > On Sat, May 01, 2004 at 02:17:04PM -0700, William Lee Irwin III wrote: > >> Would something like this help cacheline contention? This uses the > >> per_cpu data areas to hold per-cpu booleans for needing switches. > >> Untested/uncompiled. > >> The global lock is unfortunately still there. > > On Fri, May 07, 2004 at 07:53:58PM +0200, Andrea Arcangeli wrote: > > I'm afraid this cannot help, the rcu_cpu_mask and the mutex are in the same > > cacheline, so it's not just about the global lock being still there, > > it's about the cpumask being in the same cacheline with the global lock. > > Hmm. I can't quite make out what you're trying to say. If it were about > the cpumask sharing the cacheline with the global lock, then the patch > would help, but you say it should not. I don't care much about the
Since cpumask and global lock are on the same cacheline, and the global lock still force that cacheline to bounce, it shouldn't make any difference to remove the cpumask from that global cacheline, by the time you take the lock you have the cacheline local and in the next nanosecond you can use the cpumask zerocost. I understood the real cost is the bouncing of _such_ cacheline across all 512 cpus and the global lock will still generates it as far as I can tell. Though I'm mostly guessing, I certainly wouldn't be against trying your patch, I was just afraid it cannot help. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |