Jim Magee writes:
On Jun 29, 2004, at 4:22 PM, Andrew Gallatin wrote:
Philippe Jandot writes:
With the 64bit kernel of Tiger I guess that those latencies are going
to disapear ?
Will the kernel be mapped in each app address space ?
I've heard that the kernel won't be 64-bit due to fears about
breaking ABI compat with IOKit.
Can somebody who's at WWDC and has a Tiger Preview DVD confirm the 64-
or 32-bitness of the kernel on G5's? Or would that violate NDA?
The kernel remains 32-bit [for now] while supporting both 32-bit and
64-bit applications.
FWIW, I did some shark traces and found that copyin/copyout account for ~16% of the time in my ioctl path. Removing the copyin/copyout from the benchmark ioctl confirms this. As Jim Magee explained, MacOSX uses a separated 4GB + 4GB address space, so this high copyin/copyout cost for temporary mappings makes perfect sense. Copyin/copyout is no longer just a bcopy with a fault handler setup, its an on-demand remapping of memory. So I think for performance critical ioctls, I'm going to try to map out 1 page of kernel memory into each process when my device is opened. The process copies his ioctl data into that scratch buffer, calls ioctl, and copies the results out. The idea is to avoid the cost of mapping / unmapping the process VM a zillion times in the critical path. When I get a chance to implement this, I'll let you know what, if any, improvement it makes. Thanks again for your help, Drew _______________________________________________ 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.