This article is an example of why Apple was smart for going Unix. It attracts really smart geeks that can help shed light on performance issues in a way normal consumers just can't.
Unfortunately this is not the smart geek that they are looking for. He's worse than a normal consumer: he's a power user. Note how he's not done any benchmarks at all, he's just insisting that this must be the cause because the handholding Linux distros he's familiar with all use swap partitions, so OS X must just be retarded or something.
Paging is fucked in OS X, but this isn't why.
He focuses entirely on its use of swap files, which is not a problem at all, especially since the middle of the 10.5 betas. Before that, the system would only allocate new swap files and never do compaction or reclamation, so if your filesystem was normally within 10G of being full, it could page its way into filling it, and grind into a performance hell orders of magnitude worse than what he's complaining about (for years I had to reboot every 100 days or so to reclaim swap). Insisting on using fixed swap partitions made sense twenty years ago, but it sure as hell doesn't today as long as you do GC.
Paging on OS X is much higher latency than any other modern unix, but the fault lies with how VM works in the guts of Mach, not some userland configuration trivialities. Chapter 8 of Amit Singh's Mac OS X Internals has details of the implementation but doesn't go too far into why it sucks.
> Insisting on using fixed swap partitions made sense twenty years ago, but it sure as hell doesn't today as long as you do GC.
The main advantage of using fixed swap partitions is that you don't have to go through the file system to access swap. This is why swap files used to be slower on Linux with the 2.4 series of kernels -- with 2.6 and swap files, the kernel builds a map to the LBA at startup for direct physical access, so there's no performance difference any more. Shame on Linux distros that still use swap partitions in 2010.
Windows does the same, which is why Windows doesn't need (and has never supported) swap partitions, either.
However, this sort of map implies that while increasing swap size is easy, reducing the size of swap files is really difficult while the system is online, which is why Windows (and I believe Linux) don't attempt to solve this problem.
You can totally reduce the size of swap files on Linux, it's done the same way it is on OS X. It even has a nice syscall: swapoff(2) and a little utility that calls it swapoff(8) that comes with the standard util-linux package.
You create another new swapfile, turn it on, and then turn off the old one. The VM will copy all the old pages still in use in the old file and distribute them among the highest-priority enabled swaps with free space by round-robin. If you create the new swapfile sparsely, you don't even chew much disk space.
I discovered something hilarious in Linux's OOM-killer a while back. It has a bunch of heuristics for picking what process to kill next to save the rest: the very first one is "are any processes blocked in the swapoff syscall?"
Paging is fucked in OS X, but this isn't why.
He focuses entirely on its use of swap files, which is not a problem at all, especially since the middle of the 10.5 betas. Before that, the system would only allocate new swap files and never do compaction or reclamation, so if your filesystem was normally within 10G of being full, it could page its way into filling it, and grind into a performance hell orders of magnitude worse than what he's complaining about (for years I had to reboot every 100 days or so to reclaim swap). Insisting on using fixed swap partitions made sense twenty years ago, but it sure as hell doesn't today as long as you do GC.
Paging on OS X is much higher latency than any other modern unix, but the fault lies with how VM works in the guts of Mach, not some userland configuration trivialities. Chapter 8 of Amit Singh's Mac OS X Internals has details of the implementation but doesn't go too far into why it sucks.