Messages in this thread | | | Date | Mon, 21 Oct 2002 20:00:12 +0100 (BST) | From | Hugh Dickins <> | Subject | Re: [PATCH]IPC locks breaking down with RCU |
| |
On Mon, 21 Oct 2002, mingming cao wrote: > Hugh Dickins wrote: > > A much more serious point: we could certainly bring the ipc_rmid > > and ipc_unlock much closer together; but however close we bring them > > (unlock implicit within rmid), there will still be a race with one > > cpu in ipc_lock spinning on out->lock, while we in ipc_rmid null > > entries[lid].p and unlock and free the structure containing that lock. > > A simple solution I could think of for this problem, moving the per_id > lock out of the kern_ipc_perm structure, and put it in the ipc_id > structure. Actually I did this way at the first time, then I agreed > with you that moving the per_id lock into there kern_ipc_perm structure > will help reduce cacheline bouncing. > > I think that having the per_id lock stay out of the structure it > protects will easy the job of ipc_rmid(), also will avoid the wrong > preempt count problem caused by the additional check "if (out)" in > ipc_unlock() as you mentioned above. > > Is this solution looks good to you? If so, I will update the patch for > 2.5.44 soon.
Sorry, no, doesn't look good to me. I do agree that it's an easy solution to this problem, but there's no point in having gone the RCU route to avoid cacheline bouncing, if you now reintroduce it all here.
I believe, as I said, that you'll have to go further, applying RCU to freeing the entries themselves. I had toyed with the idea of never freeing entries once allocated, which is a similarly simple solution; rejected that as in general too wasteful; and concluded that RCU is a reasonable compromise - it amounts to lazy freeing, I think.
I'm happy to be overruled by someone who understands these cacheline bounce issues better than we do, but nobody else has spoken up yet.
Hugh
- 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/
| |