Linux scheduler, overscheduling performance, threads

[David Schwartz]

> 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 en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/