From owner-cvs-all  Thu May  2 23: 0:53 2002
Delivered-To: cvs-all@freebsd.org
Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39])
	by hub.freebsd.org (Postfix) with ESMTP
	id 42D7437B400; Thu,  2 May 2002 23:00:42 -0700 (PDT)
Received: from InterJet.elischer.org ([12.232.206.8])
          by rwcrmhc53.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP
          id <20020503060041.NCFY5896.rwcrmhc53.attbi.com@InterJet.elischer.org>;
          Fri, 3 May 2002 06:00:41 +0000
Received: from localhost (localhost.elischer.org [127.0.0.1])
	by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id WAA80945;
	Thu, 2 May 2002 22:58:17 -0700 (PDT)
Date: Thu, 2 May 2002 22:58:15 -0700 (PDT)
From: Julian Elischer <julian@elischer.org>
To: John Baldwin <jhb@FreeBSD.org>
Cc: Jeff Roberson <jeff@FreeBSD.org>, cvs-all@FreeBSD.org,
	cvs-committers@FreeBSD.org, Jeff Roberson <jroberson@chesapeake.net>
Subject: RE: cvs commit: src/sys/kern kern_malloc.c src/sys/vm uma_core.c
In-Reply-To: <XFMail.20020502133400.jhb@FreeBSD.org>
Message-ID: <Pine.BSF.4.21.0205022256480.80897-100000@InterJet.elischer.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk
List-ID: <cvs-all.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20cvs-all>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20cvs-all>
X-Loop: FreeBSD.ORG



On Thu, 2 May 2002, John Baldwin wrote:

> 
> So I should amend: it should probably be ok to hold locks if M_NOWAIT is
> used.  However, we should avoid holding locks for "long" periods of time.
> Esp. around non-relevant stuff like malloc (doing a malloc() usually isn't
> very relevant to the consistency of the data structure, you should almost
> always be able to make the structure consistent somehow, drop the lock,
> malloc, then lock and make the change, or just malloc first before getting
> locks and making changes).  So just as M_NOWAIT should be discouraged (and
> I've seen it used in places where it wasn't needed) holding locks across
> malloc() should be highly discouraged, IMO.

M_NOWAIT was done especially for this reason, (though of course
in tho 'old' form of locks where slp() was teh lock-of-choice)..



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