From owner-cvs-all  Mon Apr  2 20:15:17 2001
Delivered-To: cvs-all@freebsd.org
Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP
	id 5701E37B722; Mon,  2 Apr 2001 20:15:12 -0700 (PDT)
	(envelope-from alfred@FreeBSD.org)
Received: (from alfred@localhost)
	by freefall.freebsd.org (8.11.1/8.11.1) id f333FCX69312;
	Mon, 2 Apr 2001 20:15:12 -0700 (PDT)
	(envelope-from alfred)
Message-Id: <200104030315.f333FCX69312@freefall.freebsd.org>
From: Alfred Perlstein <alfred@FreeBSD.org>
Date: Mon, 2 Apr 2001 20:15:12 -0700 (PDT)
To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject: cvs commit: src/sys/sys mbuf.h src/sys/kern uipc_mbuf.c
X-FreeBSD-CVS-Branch: HEAD
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

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.
  
  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.
  
  Reviewed by: bmilekic
  
  Revision  Changes    Path
  1.74      +29 -27    src/sys/sys/mbuf.h
  1.72      +48 -45    src/sys/kern/uipc_mbuf.c


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message