You have a strong point. I was more struck by the incongruity of the following statement: "We started out using a memory mapped file to store objects in. It had some problems associated with it and was replaced with a storage engine that relied on malloc to store content. While it usually performed better than the memory mapped files performance suffered as the content grew past the limitations imposed by physical memory."
So it looks like they gave up on the "kernel knows best" approach quite a while ago. But then they show a graph, where the older mmap() approach is more than twice as fast as the malloc() approach across the entire range of the graph. They explain this in a sentence below the graph saying "Malloc suffers quite a bit here as the swap performance on Linux is rather abysmally bad. " Well, yes. But presumably that is the case we're interested in, as a cache that has room for everything is a much easier problem.
So what are we to make of the earlier contention that malloc() trumps mmap()?
Varnish was originally designed to run on FreeBSD (as PHK works on both projects). Have they changed to primarily target Linux, perhaps in response to market demand?
~ 99% of all varnish instances run on Linux. FreeBSD is still important.
Varnish Software doesn't currently have any customers who are planning on staying on FreeBSD. They are all migrating to Linux.
FreeBSD admins are hard to come by. Same with software; try getting something hip running on FreeBSD these days. Even better, try getting a support contract on it, it will not be trivial.
However, the quality of the sysadmins that prefer FreeBSD is pretty high, though. And FreeBSD is pretty neat.
> While it usually performed better than the memory mapped files performance suffered as the content grew past the limitations imposed by physical memory.
Physical memory is RAM memory. Their initial observation was:
1) If you need less memory than you have RAM installed - use malloc. Faster than file-backed mmap().
2) If you need more memory than you have RAM installed - use file-backed mmap(). Faster than malloc() + swap.
Edit: you can even see this on the graph in the article. Around time 0 it is malloc that is faster than file, then malloc sinks and file gets faster.
So it looks like they gave up on the "kernel knows best" approach quite a while ago. But then they show a graph, where the older mmap() approach is more than twice as fast as the malloc() approach across the entire range of the graph. They explain this in a sentence below the graph saying "Malloc suffers quite a bit here as the swap performance on Linux is rather abysmally bad. " Well, yes. But presumably that is the case we're interested in, as a cache that has room for everything is a much easier problem.
So what are we to make of the earlier contention that malloc() trumps mmap()?