Linux scheduler, overscheduling performance, threads

[Brian Hurt]

I apologize.  I hadn't meant to send my reply off to the list as a whole.

On Fri, 21 Jan 2000, David Schwartz wrote:

> > On Fri, 21 Jan 2000, David Schwartz wrote:
> >
> > > 	Ahh, a Java programmer, that explains it.
> >
> > So what's your experience?

> 	Absolutely. I've developed software for everything from embedded medical
> devices to clusters of servers managing tens of thousands of clients.
> 
> 	Yes. I've ported enterprise code to Solaris, Irix, and Digital UNIX.

OK.  For a second there it sounded like you were blowing me off with a
"real-programmer" attitude.  Thus my hot response.  My apologies.

> 
> 	System threads are only needed for a very small number of things:
>
[snip]
 
> 	2) One thread for each I/O operation you want to 'pend' that can't be done
> in a non-blocking fashion. (Network I/O doesn't count, disk I/O does.)
> 

I comment that databases hit the disk a lot.  Database code also tends to
page fault on data a lot, as it's jumping all over the place.

What most commercial databases (Oracle, Sybase, etc) do is exactly what
you're describing, tho- basically write their own OS, including scheduler,
to layer on top of the OS.  This was the whole idea of RawIron a couple of
years back- Oracle basically went "hey, we already have basically a full
OS in our database (including device drivers and memory management)
already- what the heck do we need Solaris for?"

On the other hand, forcing each application to write it's own minature OS
(I/O interface library, scheduling algorithm, etc) strikes me as being a
bad idea.  If the OS has good scheduling, the _only_ advantage user level
threads would have over kernel level threads would be fewer task switchs-
the advantage would be far simpler code in the applications, and less
duplication (and fewer wheels being reinvented badly).  Oracle can afford
to write it's own OS- can MySQL?

Brian



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/