On Wed, 27 Nov 2013, Davidlohr Bueso wrote:
> On Wed, 2013-11-27 at 00:56 +0100, Thomas Gleixner wrote:
> > As a side note, it might be worthwhile to epxlore whether forcing the
> > hash buckets to be cache line aligned gives us an advantage over
> > blindly increasing the hash size:
> >
> > We could avoid access across cacheline boundaries and also avoid
> > massive cache line bouncing if multiple cpus are hammering away at
> > different hash buckets which happen to reside in the same cache line.
>
> How about both enlarging the table _and_ aligning the buckets? As you
> know, increasing the size of the table also benefits (particularly in
> larger systems) in having more spinlocks. So we reduce the amount of
> collisions and alleviate contention on the hb->lock. Btw, do you have
> any particular concerns about the larger hash table patch?
I'm not against increasing the hash table size, but I'm very
interested in investigating the alignment effect as a separate issue.
> > But back to the problem at hand.
> >
> > I'm leaning towards your initial atomic_inc() approach for the
> > following reasons:
> >
> > 1) It avoids the queue/unqueue dance in the error and (*uaddr != uval)
> > case. The latter is the one you are optimizing for.
> >
> > We dirty the cache line in any case on the waiter side.
> >
> > With the optimized check, we avoid dirtying the cache line on the
> > waker side in the case that there is no waiter in flight or
> > enqueued.
> >
> > 2) It's very simple to make it OPT-IN. That allows architectures to
> > trade the mb/memory overhead with the spinlock contention overhead.
> >
> > A lot of [embedded] architectures do not care at all about the
> > futex performance simply because they do not run futex sensitive
> > workloads. And others might want to avoid the heavy smp_mb() for
> > obvious reasons.
> >
> > Make that a CONFIG switch which can be selected by the user or by a
> > select statement in the arch. That also allows archs to determine
> > the costs of that optimization just by recompiling with a different
> > .config.
>
> Would it be useful to consider NR_CPUS? Sure, you get the problem of
> when it's too little or too big, but it would deal quite well for
> smaller systems - perhaps it could at least be mentioned in the option
> description/help. I don't think users should have a direct say in the
> option, though.
Right, it does not need to be user selectable. And thinking more about
it, it shouldn't be an issue for any architecture. It's pointless for
UP though.
What might be interesting in terms of NR_CPUS is the hash table
size. That might want to scale with the system size.
Thanks,
tglx
--
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/
