From owner-freebsd-smp Sat Mar 30 5:39: 6 2002 Delivered-To: freebsd-smp@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id A497537B416 for ; Sat, 30 Mar 2002 05:39:03 -0800 (PST) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.6) with SMTP id g2UDZTw80712; Sat, 30 Mar 2002 08:35:29 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sat, 30 Mar 2002 08:35:29 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Julian Elischer Cc: Jon Mini , freebsd-smp@freebsd.org Subject: Re: Patch to "Lock struct pargs" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 27 Mar 2002, Julian Elischer wrote: > My first thought was "shouldn't the args be covered by th eproc lock" > and then I noticed the ref-count.. obviously shared between processes. > Then I thought "well why not an sx lock? I presume most processes access > these read-only. > > THEN I thought.. hey hang on.. processes access their args from user > space.. what are we storing here? so the comments in exec() etc seem to > suggest that these are not the actual args that are given to the > process, but instead some small subset used for (maybe) debugging.. if > this is so then once again it's really only read-only when used.. any > exec with a NEW set of args will create a new one. so this is similar > to the ucreds.. > > The only item we are protecting is the reference count. Everything else > should be read-only. You should only need to lock this when you are > changing the reference count. Once again an smp safe reference counting > scheme would save this locking stuff.... > > John, can you resurect your ref-counting code so we can look at it > again? I think we could use it inteh ucred case too. One of the things they've done in IRIX in moving to extremely fine-grained SMP is move from a copy-on-write notion for a number of shared structures to simply using copies. In some situations, they've moved into entirely copies, in others, they've optimized some specific cases. I don't think pargs is an example of this due to its size, but it's something worth keeping in mind. The ucred model is actually quite a strong one, assuming that the number of modifications is few (which is especially the case for ucred where most references are *never* modified: structs file, socket, etc). Doesn't pargs already work this way? I.e., if p1 modifies pargs, it doesn't affect p2? (I'm a bit source code unaware this morning since my wife is in hospital and I'm pretty much there all day). Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message