Date: Tue, 03 Apr 2001 12:50:24 -0700 (PDT) From: John Baldwin <jhb@FreeBSD.org> To: Alfred Perlstein <alfred@FreeBSD.org> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/sys mbuf.h src/sys/kern uipc_mbuf.c Message-ID: <XFMail.010403125024.jhb@FreeBSD.org> In-Reply-To: <20010403095120.E813@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 03-Apr-01 Alfred Perlstein wrote: > * 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) I have patches to acquire Giant inside of kmem_alloc, I do not have patches to deal with the lock order problem. >> > 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? It's on the SMP todo list. Bruce has sent me a script to do lots of header include checks and it apparently spits out 9000 lines of errors right now. :) I'll see if I can't get some of thise paired down at some point in time. -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ 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?XFMail.010403125024.jhb>