Messages in this thread | | | Date | Fri, 21 Jan 2000 03:03:00 -0600 (CST) | From | Brian Hurt <> | Subject | RE: Linux scheduler, overscheduling performance, threads |
| |
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@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |