From owner-freebsd-current  Wed May 29  4:20:49 2002
Delivered-To: freebsd-current@freebsd.org
Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16])
	by hub.freebsd.org (Postfix) with ESMTP id 9999837B401
	for <current@FreeBSD.ORG>; Wed, 29 May 2002 04:20:44 -0700 (PDT)
Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102])
	by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id VAA18958;
	Wed, 29 May 2002 21:19:55 +1000
Date: Wed, 29 May 2002 21:23:15 +1000 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-X-Sender: bde@gamplex.bde.org
To: Peter Wemm <peter@wemm.org>
Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>,
	Terry Lambert <tlambert2@mindspring.com>,
	Richard Wenninger <richard@richardw.net>, <current@FreeBSD.ORG>
Subject: Re: UMA lock 
In-Reply-To: <20020529070709.03852380A@overcee.wemm.org>
Message-ID: <20020529211259.L24797-100000@gamplex.bde.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-current.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%20freebsd-current>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-current>
X-Loop: FreeBSD.ORG

On Wed, 29 May 2002, Peter Wemm wrote:

> Poul-Henning Kamp wrote:
> > Uhm, I'm actually seeing the opposite behaviour as well: after I
> > changed the md(4) driver to use M_NOWAIT I still see malloc/zalloc
> > sleeping...
>
> No, this is a bug in UMA.  In certain circumstances, it calls itself
> with M_WAITOK even when it itself was called with M_NOWAIT.

Or it could be malloc/zalloc sleeping in another process.  malloc(M_NOWAIT)
may block and then wait a long time for other processes to release
resources.  This may involved the other processes sleeping, perhaps
even with M_WAITOK malloc()'s.  Buggy other processes may take arbitrary
long to release their resources.  The important points are:
- the process that called malloc(M_NOWAIT) holds all the locks that it
  needs to protect its data structures
- the process doesn't sleep itself (since sleeping might involve releasing
  critical lock(s), e.g., Giant)
- all this locking and sleeping doesn't cause deadlock.  Sleeping without
  releasing all locks would be a good way to tempt deadlock, and having
  malloc(M_NOWAIT) sleep despite being told not to would be a good way
  to sleep with some locks held.  Leaf routines like malloc() can barely
  know which locks are held, and cannot reasonably know which locks are
  safe to release.

Bruce


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