<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 5, 2014 at 12:19 AM, Mike Spreitzer <span dir="ltr"><<a href="mailto:mspreitz@us.ibm.com" target="_blank">mspreitz@us.ibm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><tt><font>Overcommitting affects the quality of service delivered
to the cloud user.  In this situation in particular, as in many situations
in general, I think we want to enable the service provider to offer multiple
qualities of service.  That is, enable the cloud provider to offer
a selectable level of overcommit.  A given instance would be placed
in a pool that is dedicated to the relevant level of overcommit (or, possibly,
a better pool if the selected one is currently full).  Ideally the
pool sizes would be dynamic.  That's the dynamic reconfiguration I
mentioned preparing for.</font></tt>
<br>
<br></blockquote></div><br></div><div class="gmail_extra">+1   I do agree that we need  a dynamic overcommit setting per compute node. Or, maybe we also need pluggable resource calculation method for resource tracker. Since each compute node may have different hypervisor, hardware or quality-of-service commitment, it does not make sense to have unified settings in scheduler or resource tracker.<br>
<br>The way preferred by I is: 1) Make our default cpu/ram filter simpler. No need to care about any overcommit ratio. Users can change the filter, if they hope that. 2) Resource tracker of each compute node can do the calculation according to its settings (or its calculation method, if it is pluggable), so that resource usage behavior can be specified to meet the unique requirement.<br>
</div><div class="gmail_extra"><br>-- <br><div dir="ltr">Qin Zhao<br></div>
</div></div>