> There are cases when we need memory rather than randomization. > Dedicated database server is such case. Postgres can give more > performance if it can use as much memory as userspace can allocate. > Many big random holes quickly leads to fails of allocations. So then > we must dramatically decrease postgres's memory limits to prevent it > from failing to allocate memory.
The problem with using as much of the address space as possible, is that then the address space eventually contains tons of valid mappings, all near each other, of course. When it contains valid mappings, erronous accesses in programs will reach over and cause either corruption (due to writes) or logical flow errors (due to reads) -- instead of instantaneous crashes. You have a bug, and you read or write something, and the code is now in an unknown state or heading down the wrong path. Unfortunately, like it or not, but the leading cause of software improvement is the instantaneous crash. Corruption leads to crashes much later, which tend to be undebuggable. Those corruption bugs are repaired much much later, only after they are repeated due to instantaneous crashes (oh look, a guard page!), or when developers -- who would be better off focused on new ideas -- spend valuable time tracing the code to find a little mistake. I know what you want. You, me, we all want faster software. But at the cost of encouraging the software to become less reliable, less maintainable, less debuggable? No, you don't want that. When software crashes, I want to be able to fix it on the spot because the bug is obvious. So that you don't hit the bug. That is why we made this decision in the past. And yes, it would be nice if the VM system could cope more gracefully with the address space when it is under high contention. But there is a massively understated benefit that comes from filling the address space with unallocated gaps. The gaps, though only on a page boundary, are finding a lot of bugs. LOTS OF THEM. It is also crashing security sensitive programs before they come under control. Unfortunately the finding finding a middle ground in the VM system is a complex problem. With perfect bug-free applications we'd want to pack the allocations right next to each other. Every day, I will prefer an application that crashes often (so that it can be fixed, or discarded) over one that is encouraged by libc to cause random and late-detected corruption. Enforcing the policy before the algorithms catch up is worthwhile.
