From owner-freebsd-hackers@FreeBSD.ORG Fri May 20 16:40:36 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3369B16A4CE; Fri, 20 May 2005 16:40:36 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A5E143D4C; Fri, 20 May 2005 16:40:32 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j4KGhHqq001347; Fri, 20 May 2005 10:43:17 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <428E12B0.9020208@samsco.org> Date: Fri, 20 May 2005 10:39:12 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Fundakowski Feldman References: <200505201340.36176.hselasky@c2i.net> <20050520151620.GF1201@green.homeunix.org> In-Reply-To: <20050520151620.GF1201@green.homeunix.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: hackers@freebsd.org cc: Hans Petter Selasky Subject: Re: problems with new the "contigmalloc" routine X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 16:40:36 -0000 Brian Fundakowski Feldman wrote: > 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. > The amount of colateral damage that has been inflicted on bus_dmamem_alloc by your changes to contigmalloc is truly impressive. Since I've spent the better part of 8 months cleaning it up, please let me know what else needs to be done so that there are no more surprises. And no, this is not my happy face. Scott