From: mingming cao <cmm@us.ibm.com>
To: Hugh Dickins <hugh@veritas.com>
Cc: torvalds@transmeta.com, linux-kernel@vger.kernel.org, akpm@zip.com.au
Subject: Re: [PATCH] Breaking down the global IPC locks - 2.5.31
Date: Thu, 22 Aug 2002 17:36:41 -0700 [thread overview]
Message-ID: <3D658399.80855551@us.ibm.com> (raw)
In-Reply-To: Pine.LNX.4.44.0208211702320.10682-100000@localhost.localdomain
Hugh Dickins wrote:
>
> Except last time around I persuaded you that ipc_lockall, ipc_unlockall
> (shm_lockall, shm_unlockall) needed updating; and now I think that they
> were redundant all along and can just be removed completely. Only used
> by SHM_INFO, I'd expected you to make them read_locks: surprised to find
> write_locks, thought about it some more, realized you would need to use
> write_locks - except that the down(&shm_ids.sem) is already protecting
> against everything that the write_lock would protect against (the values
> reported, concurrent freeing of an entry, concurrent reallocation of the
> entries array). If you agree, please just delete all ipc_lockall
> ipc_unlockall shm_lockall shm_unlockall lines. Sorry for not
> noticing that earlier.
>
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.:-)
Mingming
prev parent reply other threads:[~2002-08-23 0:32 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-05 19:48 [PATCH] Breaking down the global IPC locks mingming cao
2002-08-06 15:53 ` Hugh Dickins
2002-08-06 20:50 ` mingming cao
2002-08-20 0:30 ` [PATCH] Breaking down the global IPC locks - 2.5.31 mingming cao
2002-08-20 17:50 ` mingming cao
2002-08-21 16:51 ` Hugh Dickins
2002-08-23 0:36 ` mingming cao [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3D658399.80855551@us.ibm.com \
--to=cmm@us.ibm.com \
--cc=akpm@zip.com.au \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox