Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 02 Apr 2003 16:40:39 -0800
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Peter Wemm <peter@wemm.org>
Cc:        current@FreeBSD.org
Subject:   Re: libthr and 1:1 threading.
Message-ID:  <3E8B8307.4C5DF9D2@mindspring.com>
References:  <20030402234016.1550D2A8A7@canning.wemm.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E8B8307.4C5DF9D2>