Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 03 Apr 2001 09:18:07 -0700 (PDT)
From:      John Baldwin <jhb@FreeBSD.org>
To:        Alfred Perlstein <alfred@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:  <XFMail.010403091807.jhb@FreeBSD.org>
In-Reply-To: <200104030315.f333FCX69312@freefall.freebsd.org>

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

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:
>   Use only one mutex for the entire mbuf subsystem.
>   
>   Don't use atomic operations for the stats updating, instead protect
>   the counts with the mbuf mutex.  Most twiddling of the stats was
>   done right before or after releasing a mutex.  By doing this we
>   reduce the number of locked ops needed as well as allow a sysctl
>   to gain a consitant view of the entire stats structure.
>   
>   In the future...
>   
>     This will allow us to chain common mbuf operations that would
>     normally need to aquire/release 2 or 3 of the locks to build an
>     mbuf with a cluster or external data attached into a single op
>     requiring only one lock.
>   
>     Simplify the per-cpu locks that are planned.
>   
>   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().
   
>   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.

-- 

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.010403091807.jhb>