Bandwidth Control And Fairness In The Linux Scheduler

Abstract

Samtidig som mer og mer av datasenterindustrien fokuserer på delt infrastruktur, er nødvendigheten av skikkelig ressursstyring og prioritering av forskjellige programmer med forskjellige prioriteringer blitt enda viktigere. Etter introduksjonen av Kubernetes i 2014, har det snudd måten man håndterer infrastruktur på, på hodet. Kubernetes lar systemadministratorer kjøre forskjellige programmer med forskjellig prioritet, på den samme fysiske maskinvaren, på en sikker og feiltolerant måte. Alt dette krever mye av operativsystemet når det kommer til metoder for å oppnå slik ressursstyring. Det er her Linux virkelig skinner. Konteinere, eller kontrollgrupper, gjør dette til en lek. For å passe på bruken av CPU-tid, har Linux en CFS båndbreddekontroller som brukes av alle konteinersystemer, inkludert Kubernetes. Denne funksjonaliteten har dog et sett med fallgruver som potensielt kan gå utover ytelsen. Konteinere som bruker mer enn sin tilmålte tid blir straffet ved at de settes på pause, også kalt struping. Denne strupingen er ofte verre og mer aggressiv enn den skal være.

I vår forskning går vi i dybden på hvordan Linux sin prosess-planlegger og dens båndbreddekontroller fungerer. Vi ser på måter å minske strupingen av konteinere, og ser på forskjellige teknikker for å gjøre det. Resultatene våre viser at teknikkene gir opp til 3% bedre ytelse på ellers travle maskiner. Vi ser også at teknikkene våre reduserer kostnaden av å bruke båndbreddekontrolleren med opp til 95%.

Samtidig har vi også funnet en rekke problemer relatert til rettferdighet mellom programmer in Linux. Disse problemene kan i verste fall stoppe programmer helt, og gjøre dem treigere vesentlig treigere. Testing vår viser at problemene kunne gjøre at programmer bruker mer enn 170 ganger så mye tid som de skal. Vi har rapportert disse problemene til postlistene til Linux, sammen med våre løsninger. Noen av løsningene våre er allerede blitt en del av Linux, mens andre fortsatt diskuteres.

As more and more of the data center industry focus on shared infrastructure, the need for proper resource control between different applications with different priorities is increasing. After the introduction of Kubernetes in 2014, it has turned the table upside down when it comes to how infrastructure is managed. It has allowed system administrators to run multiple applications with different priorities on the same physical machines in a safe and fault-tolerant way. All of this requires a set of complex resource management APIs in the operating system, and this is really where the Linux kernel shines. Linux containers, or control groups, allow for this with excellent performance and flexibility. To manage the usage of CPU time between groups of processes, Linux has a CFS bandwidth controller, used by all systems managing containers, including Kubernetes. Unfortunately, it has a set of configuration pitfalls, potentially causing performance issues. Containers reaching their limit will be punished by being paused for an amount of time, also known as throttled. This throttling is often worse and more aggressive than it is supposed to be.

Our research dives deep into the Linux CFS scheduler and its bandwidth controller. We investigate the reasons for the unnecessary throttling and propose multiple techniques to avoid it. Our results show that our proposed techniques mitigate the throttling, resulting in a performance increase of about 3% on a busy system. We also found that our proposed techniques reduce the overhead of CFS bandwidth control by about 95%.

Incidentally, we also discovered a set of issues related to fairness in the Linux scheduler. These issues can stall programs on CPU congested systems in both theory and practice, slowing them down by orders of magnitude. Our testing shows that we were able to generate a real-world situation where a program took approximately 170 times longer to execute than expected. Our findings have been reported to the Linux community, together with our techniques for mitigating them. Some of our proposed techniques, implemented as kernel patches, have already been merged into the mainline kernel, while others are still in flight.