From owner-freebsd-hackers@FreeBSD.ORG Sat May 21 03:43: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 1EDD716A4CE; Sat, 21 May 2005 03:43:11 +0000 (GMT) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 550A843D9D; Sat, 21 May 2005 03:43:10 +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]) j4L3h3l6001683 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 21 May 2005 13:43:04 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j4L3h3Rx009340; Sat, 21 May 2005 13:43:03 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j4L3h3Pd009339; Sat, 21 May 2005 13:43:03 +1000 (EST) (envelope-from pjeremy) Date: Sat, 21 May 2005 13:43:03 +1000 From: Peter Jeremy To: Don Lewis Message-ID: <20050521034303.GM2129@cirb503493.alcatel.com.au> References: <20050520224928.GI2129@cirb503493.alcatel.com.au> <200505202256.j4KMuFN9055802@gw.catspoiler.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505202256.j4KMuFN9055802@gw.catspoiler.org> User-Agent: Mutt/1.4.2i cc: hackers@freebsd.org cc: hselasky@c2i.net 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: Sat, 21 May 2005 03:43:11 -0000 On Fri, 2005-May-20 15:56:15 -0700, Don Lewis wrote: >On 21 May, Peter Jeremy wrote: >> On Fri, 2005-May-20 21:51:34 +0200, Hans Petter Selasky wrote: > >>>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. > >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. Mea culpa. I thought pcb_onfault was invoked in lieu of paging but it's actually invoked after the pager has tried to bring the page in. -- Peter Jeremy