On Mon, Sep 10, 2012 at 2:04 PM, Rik van Riel <riel@xxxxxxxxxx> wrote: > On 09/10/2012 01:37 PM, Mike Waychison wrote: >> >> On Mon, Sep 10, 2012 at 5:05 AM, Michael S. Tsirkin <mst@xxxxxxxxxx> >> wrote: > > >>> Also can you pls answer Avi's question? >>> How is overcommit managed? >> >> >> Overcommit in our deployments is managed using memory cgroups on the >> host. This allows us to have very directed policies as to how >> competing VMs on a host may overcommit. > > > How do your memory cgroups lead to guests inflating their balloons? The control loop that is driving the cgroup on the host can still move the balloon target page count causing the balloon in the guest to try and inflate. This allows the host to effectively slowly grow the balloon in the guest, allowing reclaim of guest free memory, followed by guest page cache (and memory on the host system). This can then be compared with the subsequent growth (as this balloon setup allows the guest to grow as it sees fit), which in effect gives us a memory pressure indicator on the host, allowing it to back-off shrinking the guest if the guest balloon quickly deflates. The net effect is an opportunistic release of memory from the guest back to the host, and the ability to quickly grow a VM's memory footprint as the workload within it requires. This dynamic memory sizing of VMs is much more in line with what we can expect from native tasks today (and which is what our resource management systems are designed to handle). -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
