: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_at_wemm.org; peter_at_FreeBSD.org; peter_at_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 <dillon_at_backplane.com>Received on Wed Apr 02 2003 - 14:00:01 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:02 UTC