From owner-cvs-all Tue Apr 3 9:51:26 2001 Delivered-To: cvs-all@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 02FEF37B71B; Tue, 3 Apr 2001 09:51:21 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f33GpKb04029; Tue, 3 Apr 2001 09:51:20 -0700 (PDT) Date: Tue, 3 Apr 2001 09:51:20 -0700 From: Alfred Perlstein To: John Baldwin Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/sys mbuf.h src/sys/kern uipc_mbuf.c Message-ID: <20010403095120.E813@fw.wintelcom.net> References: <200104030315.f333FCX69312@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.org on Tue, Apr 03, 2001 at 09:18:07AM -0700 X-all-your-base: are belong to us. Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * John Baldwin [010403 09:19] wrote: > > On 03-Apr-01 Alfred Perlstein wrote: > > alfred 2001/04/02 20:15:12 PDT > > > > Modified files: > > sys/sys mbuf.h > > sys/kern uipc_mbuf.c > > Log: ... > > There's also some if (1) code that should check if the "how" > > operation specifies blocking/non-blocking behavior, we _could_ make > > it so that we hold onto the mutex through calls into kmem_alloc > > when non-blocking requests are made, but for safety reasons we > > currently drop and reaquire the mutex around the calls. > > > > Also, note that calling kmem_alloc is rare and only happens during > > a shortage so drop/re-getting the mutex will not be a common > > occurance. > > It is perfectly safe to drop the lock so long as the mbuf subsystem is in a > consistent state before calling kmem_alloc(). Yes, I know that, not dropping the mutex would happen when how == M_NOWAIT but the code to do that is commented out: if (1 /* XXX: how == M_NOWAIT */) mtx_unlock(&mbuf_mtx); kmem_alloc(...) if (1 /* XXX: how == M_NOWAIT */) mtx_lock(&mbuf_mtx); Basically, if kmem_alloc isn't going to sleep then there's no reason I can see to drop the mutex except for the lock order revesal problem with Giant being required by kmem_alloc. (which you have patches for) > > Remove some #define's that seemed to obfuscate the code to me. > > > > Remove an extranious comment. > > > > Remove an XXX, including mutex.h isn't a crime. > > Yes it is, and is going away soon. :) It will also be leaving other headers > such as sys/ucred.h, sys/resourcevar.h, etc. Yeah, Bruce slapped me around for this, are you planning on fixing it? Or should I proceed to remove the includes? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message