Re: libthr and 1:1 threading.

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