Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 30 Mar 2002 08:35:29 -0500 (EST)
From:      Robert Watson <rwatson@freebsd.org>
To:        Julian Elischer <julian@elischer.org>
Cc:        Jon Mini <mini@haikugeek.com>, freebsd-smp@freebsd.org
Subject:   Re: Patch to "Lock struct pargs"
Message-ID:  <Pine.NEB.3.96L.1020330083112.73912W-100000@fledge.watson.org>
In-Reply-To: <Pine.BSF.4.21.0203271039200.43629-100000@InterJet.elischer.org>

next in thread | previous in thread | raw e-mail | index | archive | help

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020330083112.73912W-100000>