From owner-freebsd-current@FreeBSD.ORG Thu Apr 3 00:58:16 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C581F37B405 for ; Thu, 3 Apr 2003 00:58:11 -0800 (PST) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BF7643F3F for ; Thu, 3 Apr 2003 00:58:10 -0800 (PST) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h338w9E04619 for ; Thu, 3 Apr 2003 10:58:09 +0200 (MEST) Date: Thu, 3 Apr 2003 10:58:09 +0200 (CEST) From: Harti Brandt To: current@freebsd.org In-Reply-To: <20030403025404.GA90770@unixdaemons.com> Message-ID: <20030403104607.T615@beagle.fokus.fraunhofer.de> References: <20030403025404.GA90770@unixdaemons.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: mbuf LOR X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2003 08:58:16 -0000 On Wed, 2 Apr 2003, Bosko Milekic wrote: BM> For what concerns DONTWAIT, you should theoretically be allowed to BM> hold a driver lock. But again, there may be a problem. Specifically, BM> I see that UMA code has some explicit Giant acquires/frees in certain BM> places. When the UMA code gets called from the malloc() code while BM> the bucket is being internally allocated in mb_alloc, you may be BM> hitting one of those paths. In fact, unless you have a specific Giant BM> acquire in the fxp_* routines you list in your trace below, that is BM> undoubtedly what is happening because there are no explicit Giant BM> acquires in the code path from m_getcl() to malloc(), so they must be BM> happening higher up in the call stack. Well, that's interesting. A month ago or so I sent a patch to smp@ with an update to the malloc page documenting the locking requirements. I got only one response. I wonder, how people are expected to correctly use an API, when that API is poorly documented (malloc(9) in this case, but mbuf(9) does not mention 'lock' either). I would ask people knowing the topic to comment on this. As soon as this EC proposal nightmare is over, I may try to write a corresponding section for mbuf(9). Regards, harti Index: malloc.9 =================================================================== RCS file: /home/ncvs/src/share/man/man9/malloc.9,v retrieving revision 1.30 diff -u -r1.30 malloc.9 --- malloc.9 24 Feb 2003 05:53:27 -0000 1.30 +++ malloc.9 17 Mar 2003 15:06:14 -0000 @@ -147,44 +147,22 @@ to return .Dv NULL if the request cannot be immediately fulfilled due to resource shortage. -Otherwise, the current process may be put to sleep to wait for -resources to be released by other processes. -If this flag is set, -.Fn malloc -will return -.Dv NULL -rather than block. Note that .Dv M_NOWAIT -is defined to be 0, meaning that blocking operation is the default. -Also note that -.Dv M_NOWAIT is required when running in an interrupt context. -.Pp -Programmers should be careful not to confuse -.Dv M_NOWAIT , -the -.Fn malloc -flag, with -.Dv M_DONTWAIT , -an -.Xr mbuf 9 -allocation flag, which is not a valid argument to -.Fn malloc . .It Dv M_WAITOK -Indicates that it is Ok to wait for resources. It is unconveniently -defined as 0 so care should be taken never to compare against this value -directly or try to AND it as a flag. The default operation is to block -until the memory allocation succeeds. +Indicates that it is ok to wait for resources. +If the request cannot be immediately fulfilled the current process is put +to sleep to wait for resources to be released by other processes. The .Fn malloc , .Fn realloc , and .Fn reallocf -functions can only return +functions cannot return .Dv NULL if -.Dv M_NOWAIT +.Dv M_WAITOK is specified. .It Dv M_USE_RESERVE Indicates that the system can dig into its reserve in order to obtain the @@ -194,6 +172,12 @@ programming. .El .Pp +Exactly one of either +.Dv M_WAITOK +or +.Dv M_NOWAIT +must be specified. +.Pp The .Fa type argument is used to perform statistics on memory usage, and for @@ -244,11 +228,37 @@ While it should not be relied upon, this information may be useful for optimizing the efficiency of memory use. .Pp -Malloc flags documented above should -.Em NOT -be used with +Programmers should be careful not to confuse the malloc flags +.Dv M_NOWAIT +and +.Dv M_WAITOK +with the .Xr mbuf 9 -routines as it will cause undesired results. +flags +.Dv M_DONTWAIT +and +.Dv M_TRYWAIT . +.Sh LOCKING CONSIDERATIONS +.Fn malloc , +.Fn realloc +and +.Fn reallocf +may not be called from fast interrupts handlers. +When called from threaded interrupts +.Ar flag +must contain +.Dv M_NOWAIT . +.Pp +.Fn malloc , +.Fn realloc +and +.Fn reallocf +must not be called with +.Dv M_WAITOK +while a mutex other than Giant is held. +Giant may or may not be held when +.Fn free +is called. .Pp Any calls to .Fn malloc -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org