I work in the Web Foundation team. We are technically responsible for the operation of the web servers for Facebook, but we’ve morphed into a team that acts as the guardian of overall reliability at Facebook. We are the people who get involved when there are severe production incidents or when there are service-level issues. As things ultimately tend to end up at the web server, we get involved in systematic issues across Facebook that affect users. Most of my work is in Linux debugging, so I spend a lot of my time on the command line working out problems in our stack. We also have people who are more focused on debugging related to RPC, caching, PHP, and those kinds of things, so we really have a broad team. The main idea of the team is that we have domain experts from across the company, and we all come together to figure out how we can drive Facebook’s reliability forward across a variety of areas.

There are two kinds of things to consider here. First, the reason that cgroupv2 is called version 2 is that it provides a API breaking change from a userspace perspective. As such, one of the main things I want to get across in the talk is for the audience to understand why we chosen to have a new version of cgroups instead of just making incremental improvements to version 1. One of the problems with adopting new kernel technology is that unless people really see the motivation and value in adopting it, you end up with many continuing to use the legacy API, which is really not an ideal situation for either side. Hopefully the talk will give those folks the motivation to go and check it out, and see how they can use it to concretely benefit their organisations. cgroups are also used by all sorts of other technology like Docker, systemd, Yarn, and others that require resource management. Most of those currently still only support version 1 (with the exception of systemd which supports v2 now and has since v226). We really need buy-in for people that are influential to get widespread adoption, understanding, and mature tooling. I see issues every now and then on various projects’ bug trackers where the true resolution for the issue posed is to move to cgroupv2, but this is not always obvious to those not familiar with current developments in kernel technologies. As such, I want to incentivise people to give version 2 a look and see if their product could benefit from using it.