site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Michael Smith writes:
On Jun 5, 2006, at 7:52 AM, Andrew Gallatin wrote:
I'm simply trying to account for why it takes ~8x as long for a simple syscall,
Which "simple" syscall?
I think lmbench uses getppid for its null syscall. Sure, you could hack getppid to run like a bat out of hell, but, as I mentioned in a different branch of this thread, what I really care about is getting into (and out of) the ioctl handler for my driver quickly. I have a hacked version of lmbench which measures this, but that's pretty hard to duplicate. See my original email from 2004 about this: http://lists.apple.com/archives/Darwin-kernel/2004/Jun/msg00099.html
and ~4x as long to get an ioctl into our driver when running MacOSX vs ppc64 linux on the same hardware. On x86 linux, when switching from the 1G/3G split to 4G/4G, we see a similar bloat of ioctl times. I had simply assumed that the 4G address space was the issue. Perhaps more of the blame lies elsewhere.
Syscall entry/exit is certainly more expensive on Mac OS than Linux. It comprises such a miniscule part of the elapsed system time on typical systems that whilst it shows up a lot on micro-benchmarks, it's not a very rewarding target for optimisation.
Our software needs a way to (quickly) request our driver pin and send (or receive) data from some large buffer. The longer this takes, the less efficient HPC computations are. Drew _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com