Re: boundary crossing latencies
Re: boundary crossing latencies
- Subject: Re: boundary crossing latencies
- From: Andrew Gallatin <email@hidden>
- Date: Wed, 30 Jun 2004 08:19:54 -0400 (EDT)
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 | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.