Messages in this thread | | | From | Eric Dumazet <> | Subject | Re: [RFC] NUMA futex hashing | Date | Tue, 8 Aug 2006 18:59:04 +0200 |
| |
On Tuesday 08 August 2006 18:49, Eric Dumazet wrote: > On Tuesday 08 August 2006 18:34, Nick Piggin wrote: > > Eric Dumazet wrote: > > > We certainly can. But if you insist of using mmap sem at all, then we > > > have a problem. > > > > > > rbtree would not reduce cacheline bouncing, so : > > > > > > We could use a hashtable (allocated on demand) of size N, N depending > > > on NR_CPUS for example. each chain protected by a private spinlock. If > > > N is well chosen, we might reduce lock cacheline bouncing. (different > > > threads fighting on different private futexes would have a good chance > > > to get different cachelines in this hashtable) > > > > See other mail. We already have a hash table ;) > > Yes but still you want at FUTEX_WAIT time to tell the kernel the futex is > private to this process. > > Giving the same info at FUTEX_WAKE time could avoid the kernel to make the > second pass (using only a private futex lookup), avoiding again the > mmap_sem touch in case no threads are waiting anymore on this futex.
After looking at kernel/futex.c, I realize we also can avoid the atomic ops (and another cacheline bouncing) done in get_key_refs()/drop_key_refs(), touching the inode i_count or mm_count refcounter)
Eric - 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/
| |