<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 7 October 2015 at 22:17, Chris Friesen <span dir="ltr"><<a href="mailto:chris.friesen@windriver.com" target="_blank">chris.friesen@windriver.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 10/07/2015 07:23 PM, Ian Wells wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
</span><span class=""><br>
The whole process is inherently racy (and this is inevitable, and correct),<br>
<br>
</span></blockquote>
<br>
Why is it inevitable?<br></blockquote><div><br></div><div>It's inevitable because everything takes time, and some things are unpredictable.<br><br></div><div>The amount of free RAM on a machine - as we do it today - is, literally, what the kernel reports to be free.  That's known by the host, unpredictable, occasionally reported to the scheduler (which takes time), and if you stored it in a database (which takes time) and recovered it from a database (which takes time) the number you got would not be guaranteed to be current.<br><br></div><div>Other things - like CPUs - can theoretically be centrally tracked, but the whole thing is distributed at the moment - compute nodes are the source of truth, not the database - which makes some sense when you consider that a compute node knows best what VMs are running and what VMs have died at any given moment.  In truth, if the central service is in any way wrong (for instance, processes outside of Openstack are using a lot of CPU, which you can't predict, again) then it makes sense for the compute node to be the final arbiter, so (occasional, infrequent) reschedules are probably appropriate anyway.<br></div><div>-- <br></div><div>Ian.<br></div><br></div></div></div>