Open Stack

I need to understand better what "holistic scheduling" means, but I agree
with you that this is not exactly what Boris has raised as an issue. I
don't have a rock solid design for what I want to do, but at least the
objectives I want to achieve are that spinning up more schedulers increases
your response time and ability to schedule perhaps at the cost of the
accuracy of the answer (just "good enough") and the need to retry your
request against several scheduler threads. I will try to look for more
resources to understand "holistic scheduling" a quick google search takes
me to a bunch of EE and manufacturing engineering type papers. I'll do more
research on this.

However, this does fit under performance for sure, it is not unrelated at
all. If there is a chance to incorporate this into a performance session I
think this is where it belongs.

-Mike Wilson


On Mon, Oct 14, 2013 at 9:53 PM, Mike Spreitzer <mspreitz at us.ibm.com> wrote:

> Yes, Rethinking Scheduler Design
> http://summit.openstack.org/cfp/details/34 is not the same as the
> performance issue that Boris raised.  I think the former would be a natural
> consequence of moving to an optimization-based joint decision-making
> framework, because such a thing necessarily takes a "good enough" attitude.
>  The issue Boris raised is more efficient tracking of the true state of
> resources, and I am interested in that issue too.  A holistic scheduler
> needs such tracking, in addition to the needs of the individual services.
>  Having multiple consumers makes the issue more interesting :-)
>
> Regards,
> Mike
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131016/11e5ed55/attachment.html>