From owner-freebsd-hackers@FreeBSD.ORG Fri May 20 22:49:45 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 D651016A4CE for ; Fri, 20 May 2005 22:49:45 +0000 (GMT) Received: from mail16.syd.optusnet.com.au (mail16.syd.optusnet.com.au [211.29.132.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 141D643D45 for ; Fri, 20 May 2005 22:49:45 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j4KMnTFR022496 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 21 May 2005 08:49:32 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j4KMnTRx009064; Sat, 21 May 2005 08:49:29 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j4KMnTfp009063; Sat, 21 May 2005 08:49:29 +1000 (EST) (envelope-from pjeremy) Date: Sat, 21 May 2005 08:49:28 +1000 From: Peter Jeremy To: Hans Petter Selasky Message-ID: <20050520224928.GI2129@cirb503493.alcatel.com.au> References: <200505201340.36176.hselasky@c2i.net> <428E12B0.9020208@samsco.org> <20050520173236.GG1201@green.homeunix.org> <200505202151.35831.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505202151.35831.hselasky@c2i.net> User-Agent: Mutt/1.4.2i cc: hackers@freebsd.org 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 22:49:46 -0000 On Fri, 2005-May-20 21:51:34 +0200, Hans Petter Selasky wrote: >Non-blocking mode has got to be supported. Else you get a nightmare rewriting >the code to support blocking mode. Your code either has to block somewhere or fail. contigmalloc() only blocks if it couldn't satisfy the request immediately. If it returns to your code, you still have the problem of needing the memory and not being able to allocate it without blocking. >Can anyone explain why "uiomove()" has to sleep, and why there is no >non-blocking "uiomove()"? As far as I can see, uiomove() only sleeps if it is asked to do a kernel<->userland move that takes more than twice a scheduler quantum. As long as you don't uiomove() ridiculous amounts of data, it should never sleep. >Will M_NOWAIT support will be added to "contigmalloc()"? When someone writes the code to do it. It's non-trivial to do properly because the blocking occurs several levels down from contigmalloc() in routines that themselves don't support M_NOWAIT. If it's that important to you, maybe you need to write the code :-). -- Peter Jeremy