Re: cross-bounday memory communication b/w user app and the Kernel.How?
Re: cross-bounday memory communication b/w user app and the Kernel.How?
- Subject: Re: cross-bounday memory communication b/w user app and the Kernel.How?
- From: Andrew Gallatin <email@hidden>
- Date: Mon, 5 Jun 2006 14:57:19 -0400 (EDT)
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden