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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
