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.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to