: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 - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
:"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
<[EMAIL PROTECTED]>
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
