出于实验原因，我在我的 OS X 10.8.2（运行 x86 LP64 内核）机器上完全禁用了交换，我知道这是一个坏主意。
当我从任何应用程序进行系统调用时，地址空间布局是什么样的？即现在，由于整个地址空间已连接（没有交换），我可以确定地访问内核中的任何有效用户地址并假设包含该地址的页面驻留在内存中吗？
我的理解是肯定的，但是读后我有点困惑，无论用户空间是 64 位还是 32 位 OS X 内核始终以 32 位模式运行，并且整个进程地址空间被切换出来，整个 4G 都被内核占用。这适用于 10.8.2 吗？如果是这种情况，那么我将无法从内核空间访问任何有效的用户空间地址，对吗？
Even in 64-bit mode, wherein kernel space is reserved at the top of the address space (i.e. 0xffffff8000xxxxxx), and even when there's no swapping, you can't access user space memory, unless you are in kernel mode acting on behalf of that user space process. The reason is because the addresses are all virtual, and you are relying on CR3 (a control register) to tell the MMU which physical pages belong to which process. So although in principle you have access to all memory in kernel mode, without CR3 you will not be able to figure out which pages belong to which process.
Thus, inside a system call, you can move data in and out of user mode memory (there's copyin/copyout for that, similar to Linux's copy_[from/to]_user) - and those also handle page faults, in case pages are actually swapped, as is the normal case. But that is only for the active user space memory - i.e. the active process. Sure, there are hacks to access other processes' CR3, but those are quite discouraged (unless you're authoring quality malware).
首先，32 位内核/64 位用户空间安排是 10.7（在客户端）或 10.6（在服务器上）之前的情况。10.5 和更早的版本只有 32 位内核，10.6 和 10.7 附带 32 位和 64 位内核（默认取决于硬件），10.8 和更新版本只有 64 位内核。
其次，对于 64 位内核，OSX 确实使用分离的内核/用户虚拟地址布局。您是正确的，在用户空间和内核之间切换时，32 位的几乎交换了整个 4GB。
至于直接取消引用用户空间指针 - 即使禁用交换也是一个坏主意，我永远不会发布这样的代码。如果你只是在胡闹，你应该没问题。（这很糟糕的一个原因是内存映射可以从另一个线程更改）