From owner-freebsd-hackers@FreeBSD.ORG Sat May 21 13:46:11 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 48E8D16A4CE for ; Sat, 21 May 2005 13:46:11 +0000 (GMT) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93EDC43D78 for ; Sat, 21 May 2005 13:46:10 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: Y1QAsIk9O44SO+J/q9KNyQ== Received: from mp-217-208-217.daxnet.no ([193.217.208.217] verified) by mailfe07.swip.net (CommuniGate Pro SMTP 4.3c5) with ESMTP id 175567134; Sat, 21 May 2005 15:46:09 +0200 From: Hans Petter Selasky To: Peter Jeremy Date: Sat, 21 May 2005 15:46:55 +0200 User-Agent: KMail/1.7 References: <200505201340.36176.hselasky@c2i.net> <200505202151.35831.hselasky@c2i.net> <20050520224928.GI2129@cirb503493.alcatel.com.au> In-Reply-To: <20050520224928.GI2129@cirb503493.alcatel.com.au> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200505211546.56111.hselasky@c2i.net> 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 Reply-To: hselasky@c2i.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2005 13:46:11 -0000 On Saturday 21 May 2005 00:49, Peter Jeremy wrote: > 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. That is not the problem. The problem is that it sleeps, which will exit the Giant lock, which means another thread can change the state of what I am about to setup meanwhile: one_thread: mtx_lock(&Giant); if(sc->gone == 0) { sc->data = contigmalloc(); } mtx_unlock(&Giant); another_thread: mtx_lock(&Giant); if(sc->data) { contigfree(); sc->data = NULL; } sc->gone = 1; mtx_unlock(&Giant); The problem is that the undefined state: "sc->data != NULL" and "sc->gone == 1" can be reached. > > >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. > On Saturday 21 May 2005 00:56, Don Lewis wrote: > > It can also sleep if it stumbles across a userland page that isn't > resident. When this happens, it will sleep until the page is retrieved > from swap. The fact that uiomove(), copyout(), copyin(), contigmalloc() and bus_dmamem_alloc() can all sleep, should be documented somewhere, so that people are not surprised. --HPS