Date: Mon, 20 Oct 2003 14:21:47 -0600 (MDT) From: Scott Long <scottl@freebsd.org> To: Alan Cox <alc@cs.rice.edu> Cc: cvs-src@freebsd.org Subject: Re: cvs commit: src/sys/dev/streams streams.csrc/sys/kernkern_descrip.csrc/sys/opencrypto cryptodev.c Message-ID: <20031020142012.R50707@pooker.samsco.home> In-Reply-To: <20031020201053.GL20658@cs.rice.edu> References: <200310200848.aa99929@salmon.maths.tcd.ie> <20031020101425.H49719@pooker.samsco.home> <20031020201053.GL20658@cs.rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 20 Oct 2003, Alan Cox wrote: > On Mon, Oct 20, 2003 at 01:58:08PM -0600, Scott Long wrote: > > On Mon, 20 Oct 2003, Scott Long wrote: > > > > > > > > > On Mon, 20 Oct 2003, Scott Long wrote: > > > > > > > On Mon, 20 Oct 2003, David Malone wrote: > > > > > > > This reminds me that we still hold Giant around pipe(2) because it isn't > > > > > > > declared MPSAFE in the syscall table. Is this still necessary? > > > > > > > > > > > I've been suspicious of this too, and I was hoping that you would have > > > > > > an answer. Can we go ahead and correct this? > > > > > > > > > > I think we may need to check the calling of pipeclose() in pipe(), > > > > > but as this is only done in an error case, it is probably safe enough > > > > > to just grab Giant for that. (The mac_* calls may need to be checked > > > > > too). > > > > > > > > pipeclose() seems to have some concept of locking, though I don't know > > > > what the implications are of it saying, 'gee, the mutex on this pipe was > > > > never initialized, so I just won't worry about locking.' Towards the > > > > end of pipeclose() Giant is acquired, though that action is likely no > > > > longer needed either. > > > > > > Nix that last part, I was looking at a stale file. pipeclose() does not > > > explicitely grab Gaint. > > > > > > Scott > > > > > > > > > > I've run several buildworlds while doing background pipe tests, all > > without any problems with WITNESS and INVARIANTS enabled on a fast SMP > > machine. I can't report any performance change since I'm only testing > > correctness now, but it looks promising. I'd advise to go ahead and > > throw the switch on this. > > > > This only changes the creation of pipes. Thus, I wouldn't expect > an observable difference. > > I believe that the actual use of pipes has been free of Giant > for some time. (In truth, there is a small bit of pmap-level > code that still acquires Giant.) > > Alan > > Right, it looks like pipe_read() and pipe_write() both run without Giant. However, in an environment like 'make -j4 buildworld' on SMP, it seems to help with Giant contention a little bit. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031020142012.R50707>