Re: [9fans] Re: Any significant gotchas?

["John S. Dyson" <toor@y1.jdyson.net>]

In article <396BD2AC.9BA22564@anu.edu.au>,
	Jason Ozolins <jason.ozolins@anu.edu.au> writes:
> Scott Schwartz wrote:
> 
>> | a select()-based approach is orders of magnitude better at throughput
>> | and maximum number of connections.
>> 
>> And yet people are constantly writing papers about how select() and poll()
>> are too inefficient, and proposing various other schemes.
> 
> Maybe so, but how does that increase the merit of spawning lots of
> threads just to get select()-like behaviour, if the experience on other
> OSs suggests that the thread approach is even less efficient than
> select()?
> 
> If people have some references to articles on approaches other than
> fd-per-thread or traditional select(), could they maybe post them to the
> group?
> 
I haven't run benchmarks for this problem exactly, but depending on
the technique for threading, you can end up with severe performance
problems due to the cache not being able to map the entire range
of memory required by the threads.  Some multi-threading schemes
require a different stack for every thread (perhaps both in user
and in kernel mode.)  The jumping from stack frame to stack frame
fills the cache very nicely :-).

A distributed kernel development that I have put on hold doesn't depend
on kernel stacks for per-process (or thread) kernel context.  This
begs the issue of the user space stack, but a carefully designed user
level multi-threading scheme might be able to minimize the user stack
needs also (in certain circumstances.)

There are some places where multi-threaded implementations for I/O
concurrency are better than poll() type implementations and vice
versa.  I implemented AIO on FreeBSD as a threaded scheme, so as
to avoid modifying the entire framework for all of the I/O types.
For RAW disk I/O, I did place hooks into the code, and had a table
driven scheme so that the optimizations to avoid threads could be
added over time.

John