From owner-freebsd-current@FreeBSD.ORG Wed Apr 2 16:00:01 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 73C4537B401 for ; Wed, 2 Apr 2003 16:00:01 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0543243FBF for ; Wed, 2 Apr 2003 16:00:01 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.9/8.12.6) with ESMTP id h33000VI087107; Wed, 2 Apr 2003 16:00:00 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9/8.12.6/Submit) id h33000uO087097; Wed, 2 Apr 2003 16:00:00 -0800 (PST) Date: Wed, 2 Apr 2003 16:00:00 -0800 (PST) From: Matthew Dillon Message-Id: <200304030000.h33000uO087097@apollo.backplane.com> To: Peter Wemm References: <20030402234016.1550D2A8A7@canning.wemm.org> cc: current@freebsd.org Subject: Re: libthr and 1:1 threading. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2003 00:00:01 -0000 :Terry Lambert wrote: :> Peter Wemm wrote: :> > No. It gives the ability for a thread to block on a syscall without :> > stalling the entire system. Just try using mysqld on a system using libc_r :> > and heavy disk IO. You can't select() on a read() from disk. Thats the :> > ultimate reason to do it. The SMP parallelism is a bonus. :> :> Bug in FreeBSD's NBIO implementation. A read() that would result :> in page-in needs to queue the request, but return EAGAIN to user :> space to indicate the request cannot be satisfied. Making select() :> come true for disk I/O after the fault is satisfied is a seperate :> issue. Probably need to pass the fd all the way down. : :Umm Terry.. we have zero infrastructure to support this. : :Cheers, :-Peter :-- :Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com :"All of this is for nothing if we don't go to the stars" - JMS/B5 It would be a very bad idea anyway. If someone is that dependant on detecting page-fault or page-in behavior during I/O then they ought to be using AIO (which does queue the request), not, read(), or they should wire the memory in question. I think I know what Terry wants... the best of both worlds when faced with the classic performance tradeoff between a cached synchronous operation and an asynchronous operation. Giving read() + NBIO certain asynchronous characteristics solves the performance problem but breaks the read() API (with or without NBIO) in a major way. A better solution would be to give AIO the capability to operate synchronously if the operation would occur in a non-blocking fashion (inclusive of blockages on page faults), and asynchronously otherwise. -Matt Matthew Dillon