Well, if you have a bunch of realtime / high priority threads running,
they quite possibly can cut into your IO performance. If you're doing
large reads/writes that bypass the cache (>64KB or on request via ioctl)
the driver (provided the device is fairly modern) should be able to do dma
into/outof userspace which can be a nice win.
I'm actually working on rewriting an old interrupt latency benchmark
(predating the programmable timers in R4.x) to see if I can get some
real numbers here. Technically interrupts should be fieldable in the 5-10us
range provided there's not a misbehaving driver disabling IRQs for extended
periods of time.
> > Networking on BeOS is not stellar, but it's servicable and performance
> > issues are being worked on. Raw disk IO is actually pretty good, to my
> > knowledge, though obviously real numbers are what you want here and
>
> Raw disk and FS performance are really different. DOS gets decent raw
> disk performance, but our experience is that app ports to RTLinux get
> an enormous benefit from ext2.
I believe Dominic found that BFS tends to see about 5% worse performance
for raw streaming IO than reading/writing the raw device. File creation/
deletion/etc suffers some due to journaling and indices (though indices can
be turned off). Not much seems to beat ext2 for pure speed.
Brian
-
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/