Date: Wed, 02 Apr 2003 16:54:09 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: current@freebsd.org Subject: Re: libthr and 1:1 threading. Message-ID: <3E8B8631.67435BC8@mindspring.com> References: <20030402234016.1550D2A8A7@canning.wemm.org> <200304030000.h33000uO087097@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E8B8631.67435BC8>