> On Tue, Jul 30 2002, Bill Davidsen wrote:
> > Now a request, if someone is running a database app and tests this I'd
> > love to see the results. I expect things like LMbench to show more threads
> > ending at the same time, but will it help a reall app?
>
> Note that the deadline i/o scheduler only considers deadlines on
> individual requests so far, so there's no real guarentee that process X,
> Y, and Z will receive equal share of the bandwidth. This is something
> I'm thinking about, though.
I'm not sure that equal bandwidth and deadline are compatible, some
processes may need more bandwidth to meet deadlines. I'm not unhappy about
that, it's the reads waiting in a flood of write or vice-versa that
occasionally make an app really rot.
> My testing does seem to indicate that the deadline scheduler is fairer
> than the linus scheduler, but ymmv.
>
> > I bet it was tested briefly on IDE, my last use of IDE a week or so ago
> > lasted until I did "make dep" and the output went all over every attached
> > drive :-( Still, nice to know it will work if IDE makes it into 2.5.
>
> :/
>
> I'll say that 2.5.29 IDE did work fine for the testing I did with the
> deadline scheduler, at least it survived a dbench 64 (that's about the
> testing it got).
Hum, looks as if I should plan to retest with 29 and the deadline patches.
My personal test is a program doing one read/sec while making CD images
(mkisofs) on a machine with large memory. It tends to build the whole
700MB in memory and then bdflush decides it should be written and the read
latency totally goes to hell. I will say most of this can be tuned out at
some small cost to total performance (thanks Andrea).
-- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/