From: mingming cao <cmm@us.ibm.com>
To: Hugh Dickins <hugh@veritas.com>
Cc: torvalds@transmeta.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Breaking down the global IPC locks
Date: Tue, 06 Aug 2002 13:50:06 -0700 [thread overview]
Message-ID: <3D50367E.85EF0968@us.ibm.com> (raw)
In-Reply-To: Pine.LNX.4.44.0208061556160.1545-100000@localhost.localdomain
Hugh Dickins wrote:
>
> 1. To reduce dirty cacheline bouncing, shouldn't the per-id spinlock
> be in the kern_ipc_perm structure pointed to by entries[lid], not
> mixed in with the pointers of the entries array? I expect a few
> areas would need to be reworked if that change were made, easy to
> imagine wanting the lock/unlock before/after the structure is there.
>
You are right at the cacheline bouncing issue. I will make that change.
> 2. I worry more about the msg_ids.sem, sem_ids.sem, shm_ids.sem which
> guard these areas too. Yes, there are some paths where the ipc_lock
> is taken without the down(&ipc_ids.sem) (perhaps those are even the
> significant paths, I haven't determined); but I suspect there's more
> to be gained by avoiding those (kernel)semaphores than by splitting
> the spinlocks.
>
I don't worry the ipc_ids.sem very much. They are used to protect the
IPC info, which is not updated quiet often (by operation such as
semctl()). Significant IPC operations, like semop(), msgsnd() and
msgrcv(), need the access to the IPC ID, where only the ipc_lock() is
needed.
> 3. You've added yet another level of locking, the read/write-locking
> on ary_lock. That may be the right way to go, but I think there's
> now huge redundancy between that and the ipc_ids.sem - should be
> possible to get rid of one or the other.
>
They look similar at the first glance. But they serve for different
purposes. The ipc_ids.sem is used to protect the IPC infos, while the
ary_lock is used to protect the IPC ID array. This way we could do
semctl() and semop() in parallel.
> 4. You've retained the ids->ary field when you should have removed it;
> presumably retained so ipc_lockall,ipc_unlockall compile, but note
> that now ipc_lockall only locks against another ipc_lockall, which
> is certainly not its intent. If it's essential (it's only used for
> SHM_INFO), then I think you need to convert it to a lock on ary_lock.
>
Thanks for point this out to me. I need to get ipc_lockall/ipc_unlockall
fixed.
Mingming
next prev parent reply other threads:[~2002-08-06 20:52 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 [this message]
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
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=3D50367E.85EF0968@us.ibm.com \
--to=cmm@us.ibm.com \
--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