From owner-freebsd-current@FreeBSD.ORG Wed Apr 2 16:56:00 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 1610337B401 for ; Wed, 2 Apr 2003 16:56:00 -0800 (PST) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79FCF43FB1 for ; Wed, 2 Apr 2003 16:55:59 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0436.cvx22-bradley.dialup.earthlink.net ([209.179.199.181] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 190t1H-0006WT-00; Wed, 02 Apr 2003 16:55:56 -0800 Message-ID: <3E8B8631.67435BC8@mindspring.com> Date: Wed, 02 Apr 2003 16:54:09 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon References: <20030402234016.1550D2A8A7@canning.wemm.org> <200304030000.h33000uO087097@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a489ccf3259ccd0c83b1ec8186f447c1973ca473d225a0f487350badd9bab72f9c350badd9bab72f9c 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:56:00 -0000 Matthew Dillon wrote: >Peter Wemm wrote: > :Terry Lambert 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. > > 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 don't understand this statement. Specifically, we're not talking about a "dependency", we are talking about optimizing the number of stalls in that case that a page-in becomes necessary in uioread(), and it is a result of a read on a non-blocking file descriptor. The only thing really missing is knowing the original request was a read() of a non-blocking descriptor at the time you initiated the uioread() operation. That's one parameter to two functions, and a struct fileops flag, and a struct vnops flag additional to get the information to where it's needed. And then a flag to the underlying uioread "VM pig tricks" code to tell it to come back after triggering the fault. What am I missing? > 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. How does this break the read() API? The read() API, when called on a NBIO fd is *supposed* to return EAGAIN, if the request cannot be immediately satisfied, but could be satisfied later. Right now, it blocks. This looks like breakage of disk I/O introducing a stall, when socket I/O doesn't. If this breaks read() semantics, then socket I/O needs fixing to unbreak them, right? > 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. This is a useful optimization, but it's different from what I want. What I want is disk I/O "in the pipeline" to not stall a read() request on an NBIO fd, the *same* way that network I/O "in the pipeline" doesn't stall a read() request on an NBIO fd. Does this make more sense? I actually think Peter definitely "gets" what I want; I just think he thinks it's harder to implement than it actually is: there's not a lot of "infrastructure" required, I think. -- Terry