A snapshot of my understanding before tackling the memory coordinator

Now that I finished writing the vCPU scheduler for project 1, I’m moving on to the second part of the project called the “memory coordinator” and here I’m posting a similar blog post to a snapshot of my understanding of project 1 , the motivation being that I take for granted what I learned throughout graduate school and rarely celebrate these little victories.

This post will focus on my unknowns and my knowledge gaps as it relates to the memory coordinator that we have to write in C using libvrt. According to project requirements, the memory coordinator should:

dynamically change the memory of each virtual machine, which will indirectly trigger balloon driver.

Questions I have

As I chip away at the project, more questions will inevitably pop up and when they do, I’ll capture them (but in a separate blog post). So here’s my baseline understanding of what a memory coordinator:

• What are the relevant memory statistics that should be collected?
• Will the resident set size (RSS) be relevant to the decision making algorithm? Or it is  irrelevant?
• What is the upper and lower bounds of memory consumption that triggers the ballooning driver to page memory out or page memory in?
• Will the balloon driver only trigger for virtual machines that are memory constrained?
• Does the hypervisor’s memory footprint matter (I’m guessing yes, but to what extent)?