3 ms·
This is another misinformed rant. > Varnish I/O model is ignorant of TLB flushing, instruction cache, VM hints like madvise(2), and the overhead (and downright
by reza_n 9y ago
This is another misinformed rant.
> Varnish I/O model is ignorant of TLB flushing, instruction cache, VM hints like madvise(2), and the overhead (and downright difficult job) of an OS scheduler.
TLB flushing is a hardware problem, not a software problem. Instruction cache? Last I checked, the varnishd binary is about 2MB and uses very predictable jumping and straight function calling. Im pretty sure your going to be getting a 99% instruction cache hit rate. Madvise is used in Varnish's storage engine's, and there seems to be little interest or knowledge about how Varnish uses storage here.
> If my points didn't have some validity, Fastly would not have done what they did.
Can you expand on what Fastly did? They published a non locking memory allocator? So the claim is that memory allocation is the bottleneck and jemalloc is not suitable?
Sounds like someone might be stuck in performance hell and you are trying to draw parallels to Varnish which simply don't exist!
- kev009 9y agoYou don't understand TLB. It is distinctly not a hardware problem. A TLB is a content addressable memory and the mappings and flushing are done by.. software. You flush it every time you context switch, and pretty much fully all the time with KPTI now that PCID's 4096 ASIDs can't safely save anything other than the kernel and runnable process. My point about madvise protects against PHKs post claiming memory pool objects will always be paging in and out, which is false and again a memory pool is desirable for certain uses as it guarantees maximum latency and avoids very heavy locking in the VFS for high concurrency.