Messages in this thread | | | From | Eric Dumazet <> | Subject | Re: [RFC] NUMA futex hashing | Date | Tue, 8 Aug 2006 18:49:28 +0200 |
| |
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.
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/
| |