> 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.
This is why a pure user-space threading library is not very good for a
database. Fortunately, this is not currently a problem for Linux like it is
for FreeBSD.
> 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?"
Well, ideally, Linux should be the OS. <G>
> 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?
For most applications, pending too many disk I/Os just hurts you. In any
event, if a thread is waiting for disk I/O, it's not on the run queue, so
Linux shouldn't have much problem with it. I don't think it's common that a
large number of threads waiting to on disk I/O will all become ready to run
at the same time.
What's probably needed is a very good many-to-one threads implementation.
That Linux doesn't have. And you need it (or at least parts of it) to
implement Java well.
DS
-
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/
This archive was generated by hypermail 2b29 : Sun Jan 23 2000 - 21:00:26 EST