On Sat, 18 Jun 2016, Manfred Spraul wrote:
sysv sem has two lock modes: One with per-semaphore locks, one lock mode with a single big lock for the whole array. When switching from the per-semaphore locks to the big lock, all per-semaphore locks must be scanned for ongoing operations. The patch adds a hysteresis for switching from the big lock to the per semaphore locks. This reduces how often the per-semaphore locks must be scanned.
Isn't this very arbitrary depending on the workload? Ie the other way around: when we have a lot more simple ops going on not so good. While I'm more worried about combinations that could cause enough complex ops to always delay taking the finer grained lock, this change also obviously makes simple ops more expensive on newly created segments. In general I don't trust magic numbers much. What sort of numbers have you seen with this patch? Is this a real concern (particularly because a lot of the sem->lock work was because real world workloads were doing a lot more simple ops afaicr)? Thanks, Davidlohr -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
