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 10:52:43 -0400 (EDT)
Michael Smith writes:
>
> On Jun 2, 2006, at 12:45 PM, Andrew Gallatin wrote:
>
> > Terry Lambert writes:
> >> are different address spaces. Unlike most 32 bit OS's intended to
> >> operate on small machines, MacOS X does not map the user process
> >> address space into the kernel address space, so a direct copy is not
> >> possible for a user space buffer when you are operating in kernel
> >> space (or vice versa - which is not possible even on OS's that map
> >> process in, since they don't map the kernel out into user land). The
> >> benefit of doing this is that instead of having only 2G or 3G for
> >> your
> >> programs, you get the full 4G. It also means that instead of only
> >> having 2G or 1G for the kernel's use, you have the full 4G - that
> >> effectively means that the kernel can do a lot more housekeeping in
> >> its own memory, and can theerefore run on machines with large amounts
> >> of physical memory (8G, 16G, etc.) without running out of address
> >> space.
> >
> > The downside of this is that things like syscalls take about 8x long
> > as linux on the same hardware the last time I measured them.
>
> The 4/4 split does not noticeably affect the speed of system calls.
>
> It does, however, make it possible to run applications on datasets
> that you could not otherwise run, and to support hardware that you
> could not otherwise support. Again, something of a tradeoff in the
> name of usefulness.
>
> I'm curious as to your measurement methodology, by the way. I have
> seen very different numbers from a very reliable source.
I'm simply trying to account for why it takes ~8x as long for a simple
syscall, 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.
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