There's a table on the 2nd page of the paper that gives a summary of what goes on when the VM's container is initialised the first time:

INITIALIZATION PHASE:
(1) Start the VM.

(2) Fetch the container image and the function's code.

(3) Initialize the container.

(4) Start the language runtime such as Python or PHP.

(5) Load common libraries into memory.

(6) Load the function code into memory.

(7) Optionally, do JIT compilation.
INVOCATION PHASE:

(8) Invoke the function multiple times as needed.
SHUTDOWN PHASE:

(9) Stop the container if it receives no requests for X minutes (X=10/20/10 minutes for AWS/Azure/OpenWhisk respectively).

(10) Optionally, stop the VM

>I think this needs to be more specific; what resources are exactly locked to a VM?

Steps 1-7 are time-consuming processes, which load a container into memory so that step 8 can run rapidly when invoked later. Step 8 can be invoked an unlimited number of times on a VM once steps 1-7 have completed. Only the first Function execution on a VM pays the startup penalty.

>Are they pinning VMs to specific CPUs or something that prevents the host from scheduling other tasks there? If so, why?

They're pinning memory to VMs in their FaaS infrastructure, which in turn is memory consumed on their physical servers. A VM uses some number of MBs of memory to host a Function's unique container, its runtime, and its executables. Meta's FaaS solution completes several trillion operations per day, which is in the tens of millions per second avg. This relatively small amount of memory per VM becomes enormous at tens-of-millions-per-second scale.

>If so, why?

The resources are pinned to the memory by the first function initialisation, so that if there's a second request for the same Function, it can be executed on a pre-warmed VM, without going through the time-consuming steps 1-7. A trade-off between memory-consumption and time, both cost money.

There is some optimal amount of time between the end of the final Function invocation of step 8, and the start of step 9. If the amount of time is 0-seconds, then every Function request goes through steps 1-7. While if the amount of time is 1-hour, at midnight when Meta's large one-a-day batch jobs run, most of the servers fill with idle VMs until 1am, waiting to satisfy a batch-job that never instantiates.

Given that infrastructure cannot be aware of which Function execution is "the final Function invocation", it's challenging to pin this amount of time down. In a public cloud, that optimal amount of time is set in the 10s of minutes. In Meta's case, as a private cloud provider to themselves, they have a unique awareness to the usage pattern of their Functions, and therefore can predict more acurately that they don't need 10-minute-idle-Functions. They've instead been able to reduce the idle time to 1 minute. This releases Containers & VMs, and returns memory back into the server pool.

>do you have some additional sources you could point me to, or are you also basing all this on this one paper?

Everything I've said about Meta is based on this paper, because it comprehensively describes Meta's unique circumstances, and how they approached the problem. The paper itself has dozens of additional sources.