Greetings, Robert.
Looking over your test program, I don't think you are actually testing
the elevator algorithm at all. There are a couple of key flaws:
* The reads and writes are synchronous, so the elevator algorithm
at _most_ gets to effect the blocks within a single read or
write (ie - inside the same file).
* The fact that you have written the files out all at once will not
place all 240 megs of data consecutively on the disk. The file
system spreads out data on disk to allow breathing room for
adding new files, or appending to existing files. In particular,
this means that although large subsections of blocks that are
adjacent in the logical file _will_ be close by on disk, you cannot
generalize from this that these large subsections will be close to
each other - either within a single file, or between the files
created by the test program.
* Unless the partition is completely empty, existing file data will
effect where new data is placed (and in particular how well
co-located
it can be).
A better approach to testing the elevator algorithm would be to write
directly to a raw device, instead of going through the file system.
This would allow you better control over actual disk placement of
blocks, and let you know what you were testing. It would also allow you
to make sure that subsequent re-tests would be repeatable, as they
shouldn't be effected by existing data. Finally, to do this test right,
you need to be able to issue multiple IO requests to the disk at
essentially the same time. To do this, you'll probably need to go
multithreaded, and use a barrier of some sort to make sure the threads
stay synchronized.
Best regards,
-Rob von Behren
Robert Cohen wrote:
>
> Here are the latest results for my elv_test elevator benchmark.
> This benchmark gives three numbers, a baseline figure for writing
> sequentially and write and read results for writing and reading in a
> pattern designed to give the elevator a hard time.
> The source code is available at
> http://tltsu.anu.edu.au/~robert/elv_test.c.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Oct 07 2000 - 21:00:14 EST