Hi Devin Ben-Hur,

We’ve eventually updated glog and I wasn’t the one doing this, however, from what I understood by talking to the person who did, the change is not even included in the latest glog release yet. So, he had to manually cherry-pick necessary patches.

As for the overhead — the key point here is that we’re not seeing this behavior on small VMs. Neither on AWS nor on the in-house VMware. And the reason why we started debugging it at all was because with the same or greater CPU/RAM limits per container, we were seeing much worse performance than on VMs.

To be honest, I was too lazy to dig deeper and understand what exactly was causing slowness in fadvise. Btw, we measured it on 4.15 and the problem does not exist there. There were several big patches since 4.4.

But, my naive understanding was that on VMs, we get dedicated, completely virtualized kernels, which only compete for CPU/RAM/IO on the hypervisor level, but not for any possible kernel resources: mutexes, locks, caches, etc. And hence, fadvise and any other calls would be as fast, as they are on the physical hardware with (Host — Hypervisor overhead) / number of tenants amount of resources.