boundary crossing latencies
I'm working on commercial OS-bypass networking software shared among Linux, FreeBSD, MacOSX and others (Solaris, windows, etc). Due to the shared nature of the code, we've been using ioctls, since they work everywhere. The latency to complete an ioctl to our driver is becoming more important. Unfortunately, MacOSX seems to be rather bad at this. I performed micro-benchmarks to quantify this. (see table below). In addition to a null (getppid()) syscall, I timed a simple ioctl which does nothing more than copy a few ints into and out of the driver. I found that MacOSX 10.3.3's ioctl takes nearly 4x as long as the same code under linux ppc64 on the same exact G5. And it takes 8x as long as the same ioctl on an AMD64. Given that ioctls are so slow, I hoped the Mach IPC based IOKit UserClient method of boundary crossing would be faster. So I downloaded the "SimpleUserClient" demo, removed the IOLogs and printfs, and instrumented it by timing how long it takes to call "IOConnectMethodScalarIStructureO" 100,000 times (this does something roughly equivalent to the ioctl I'm timing above -- copies a few ints in and out). It looks like IOKit User Clients are even worse than ioctls. A user client call takes 7x as long as an ioctl under linux ppc64 on the same G5. And 15x as long as an ioctl on the AMD64 competition. Is Apple planning to improve either ioctl or IOKit user-client latencies? Thanks, Drew Platform null (us/call) ioctl(us/call) user client(us/call) -------- ----------- -------- ------------------- G5/linux2.6.5 0.2112 0.6679 N/A G5/OSX 10.3.3 1.4568 2.5152 4.7201 P4/linux2.4.23 0.4179 0.6207 N/A P4/linux2.6.6 0.3833 0.6502 N/A P4/FreeBSD 5.2 0.4827 1.1024 N/A AMD/linux2.4.21 0.0982 0.3131 N/A "G5" is a dual 2.0GHz G5 "P4" is a dual 3.06GHz Xeon "AMD" is a dual opteron 244 running 64-bit linux. _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.
participants (1)
-
Andrew Gallatin