Date: Fri, 20 May 2005 11:16:20 -0400 From: Brian Fundakowski Feldman <green@FreeBSD.org> To: Hans Petter Selasky <hselasky@c2i.net> Cc: hackers@FreeBSD.org Subject: Re: problems with new the "contigmalloc" routine Message-ID: <20050520151620.GF1201@green.homeunix.org> In-Reply-To: <200505201340.36176.hselasky@c2i.net> References: <200505201340.36176.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, May 20, 2005 at 01:40:35PM +0200, Hans Petter Selasky wrote: > Hi, > > I just hit some problems with the new "contigmalloc()" routine in > FreeBSD-6-current, which is used by "bus_dmamem_alloc()". > > Firstly it locks Giant, which cause locking order reversals when allocating > memory from certain contexts. Secondly it sleeps even if flag M_NOWAIT is > passed. Thirdly it does not support flag M_ZERO. Read the documentation. It supports M_ZERO just fine, and it does _not_ support M_NOWAIT. > Can someone explain why these changes have been made? Changes? > Why doesn't "contigmalloc()" give a warning when an invalid flag is passed? The kernel would be significantly larger and almost certainly slower if it were to double-check that everywhere any bit fields are used that flags that are not defined to have any behavior are unset. > Are these bugs in "contigmalloc()"? No. > Or does the code using "contigmalloc()" have to be changed? Yes. The i386 bus_dmamem_alloc(), for example, calls it with M_NOWAIT which is not a valid flag. The contigmalloc(9) page is not entirely truthful about the fact that it doesn't sleep at all -- it calls those routines which can. They can both be documented to require no locks to be held when being called, except for M_NOWAIT specifically in the one-page-or-less allocation case. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050520151620.GF1201>