Kirk Strauser wrote:
Kris Kennaway wrote:

No, if it's reading in 16 byte units it will explain the terrible performance.

No, it's actually doing 4096-byte reads. That was just an example of what I meant.

I don't understand what you meant by "It's also doing a lot of lseek()s to what is likely the current position anyway (example: seek to 0x00, read 16 bytes, seek to 0x10, etc.)." then. Please show a typical part of the ktrace output.


>  Since I wrote that, though, I wrote a program to do
1,000,000 seeks to position 0, and it ran immeasurably fast. I'm guessing that lseek() is optimized to not do anything if you ask it to move to the position you're already at.

Any other thoughts? There definitely aren't any setbuf() calls, and no matter what it still takes 100 times more kernel overhead on Linux than FreeBSD. Speaking of which, I think my next experiment will be to try the Linux binaries on FreeBSD and see if it behaves similarly.

_______________________________________________ mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to