From owner-freebsd-current@FreeBSD.ORG Wed Apr 2 16:42:28 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 695EB37B401 for ; Wed, 2 Apr 2003 16:42:28 -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 D3F9A43F85 for ; Wed, 2 Apr 2003 16:42:27 -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 190so9-0003FO-00; Wed, 02 Apr 2003 16:42:23 -0800 Message-ID: <3E8B8307.4C5DF9D2@mindspring.com> Date: Wed, 02 Apr 2003 16:40:39 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Wemm References: <20030402234016.1550D2A8A7@canning.wemm.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a447bfd328ddd2488114e92edc9b7c3d73387f7b89c61deb1d350badd9bab72f9c350badd9bab72f9c cc: csujun@21cn.com 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:42:28 -0000 Peter Wemm wrote: > 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. There are a couple of PROC_LOCK()/PROC_UNLOCK() pairs in trap_pfault(), and there's the translation of the fault for emulators, which isn't protected at all in trap(), but there's not really any proc references which are held for a long time in the fault handing path, at least for T_PAGEFLT. Hmm. The problem comes down to the vnops version of the struct fileops, which comes down to VOP_READ which comes down to ffs_read, which then falls down to "try get the data from the object using vm tricks" -- uioread(). Is ENABLE_VFS_IOOPT permanently disabled? Nope -- enabled; I see a prototype unconditionalized in uio.h. This doesn't look too hard to implement on a per struct fileops, per-VFS basis; it's not like there's sleeping on a process, rather than a vnode lock or anything; mostly everything is marked "GIANT_REQUIRED" after a certain point. Worst case, you could create a kernel-only thread pool in whose context you operated, after validating credentials (obviously). -- Terry