Agree. I was worrried about the case when shm_destroy() is called while
trying to do a shm_get_stat(). But since shm_ids.sem is used to protect
almost every shm operations, so I think that removing the ipc_lockall()
totally should be safe.
> You convinced me that it's not worth trying to remove the ipc_ids.sems,
> but I'm still slightly worried that you add another layer of locking.
> There's going to be no contention over those read_locks (the write_lock
> only taken when reallocating entries array), but their cachelines will
> still bounce around. I don't know if contention or bouncing was the
> more important effect before, but if bouncing then these changes may
> be disappointing in practice. Performance results (or an experienced
> voice, I've little experience of such tradeoffs) would help dispel doubt.
> Perhaps, if ReadCopyUpdate support is added into the kernel in future,
> RCU could be used here instead of rwlocking?
Hmm...note sure about the tradeoffs either. Having one lock per IPC ID
does make sense to me, but the cacheline bouncing should also be avoid.
I need to re-think about this read-write lock and the ipc_ids.sems.
> Nit: I'd prefer "= RW_LOCK_UNLOCKED" instead of "=RW_LOCK_UNLOCKED".
I like it better too.:-)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/