6 ms·
Interesting story. I don't know anything about the Linux scheduler, but if one core out of 96 is busy chasing after those ghost allocations, why would a networ
by alain94040 2mo ago
Interesting story.
I don't know anything about the Linux scheduler, but if one core out of 96 is busy chasing after those ghost allocations, why would a network thread not use one of the other 95 cores, and instead be stuck for seconds? Unless that one core is blocking the entire kernel, but then that would be a lot more visible instantly.
- neerajsi 2mo agoIt's probably a "bottom half", which is tightly bound to the CPU where the interrupt landed. And probably the memcg iteration uses a spin lock, which disables bottom half execution. On NT, this style of problem would be slightly less likely. The job object, which is NT's memcg equivalent, is a handle based object that naturally goes away when the owning process dies. I also bet systemd would have native mechanisms to clean this memcg state up if it was used for this purpose. Seems like a bug in the AWS ecs code.