4 ms·
> […] thus letting the OS handle the dynamic allocation needed for each connection. This is what PHK did when designing Varnish (IIRC): instead of dealing with
by throw0101a 5y ago
> […] thus letting the OS handle the dynamic allocation needed for each connection.
This is what PHK did when designing Varnish (IIRC): instead of dealing with lots of files on its own (like Squid), just create some files and do a malloc() on them and let the OS do the work:
* https://varnish-cache.org/docs/trunk/phk/notes.html https://varnish-cache.org/docs/trunk/phk/notes.html
One discussion (many others):
* https://news.ycombinator.com/item?id=4874304 https://news.ycombinator.com/item?id=4874304
- mrich 5y agoIt's not malloc() but mmap() if I understand correctly. It's a beautifully powerful function :) https://man7.org/linux/man-pages/man2/mmap.2.html https://man7.org/linux/man-pages/man2/mmap.2.html
- richardwhiuk 5y agoIt kind of undercuts the argument, because the dynamic allocator basically just uses mmap as well. (Some allocators, like glibc may also use brk, but it's possible to write a fully functional allocator with only mmap).
- mrich 5y agoI think the original point still stands. When the application tries to handle memory pressure itself by writing data structures to disk, it will hit the case where the kernel has already paged that memory out, has to reload it, only to write it to disk and free the memory afterwards.