Date: Tue, 3 Apr 2001 09:51:20 -0700 From: Alfred Perlstein <alfred@FreeBSD.org> To: John Baldwin <jhb@FreeBSD.org> 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> In-Reply-To: <XFMail.010403091807.jhb@FreeBSD.org>; from jhb@FreeBSD.org on Tue, Apr 03, 2001 at 09:18:07AM -0700 References: <200104030315.f333FCX69312@freefall.freebsd.org> <XFMail.010403091807.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* John Baldwin <jhb@FreeBSD.org> [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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010403095120.E813>