Still the point from Chris is valid. I guess the main reason openstack is going with multiple concurrent schedulers is to scale out by distributing the load between multiple instances of schedulers because 1 instance is too slow. This discussion is about coordinating the many instances of schedulers in a way that works and this is actually a difficult problem and will get worst as the number of variables for instance placement increases (for example NFV is going to require a lot more than just cpu pinning, huge pages and numa).
Has anybody looked at why 1 instance is too slow and what it would take to make 1 scheduler instance work fast enough? This does not preclude the use of concurrency for finer grain tasks in the background. On 10/9/15, 11:05 AM, "Clint Byrum" <cl...@fewbar.com> wrote: >Excerpts from Chris Friesen's message of 2015-10-09 10:54:36 -0700: >> On 10/09/2015 11:09 AM, Zane Bitter wrote: >> >> > The optimal way to do this would be a weighted random selection, where the >> > probability of any given host being selected is proportional to its >> > weighting. >> > (Obviously this is limited by the accuracy of the weighting function in >> > expressing your actual preferences - and it's at least conceivable that >> > this >> > could vary with the number of schedulers running.) >> > >> > In fact, the choice of the name 'weighting' would normally imply that it's >> > done >> > this way; hearing that the 'weighting' is actually used as a 'score' with >> > the >> > highest one always winning is quite surprising. >> >> If you've only got one scheduler, there's no need to get fancy, you just >> pick >> the "best" host based on your weighing function. >> >> It's only when you've got parallel schedulers that things get tricky. >> > >Note that I think you mean _concurrent_ not _parallel_ schedulers. > >Parallel schedulers would be trying to solve the same unit of work by >breaking it up into smaller components and doing them at the same time. > >Concurrent means they're just doing different things at the same time. > >I know this is nit-picky, but we use the wrong word _A LOT_ and the >problem space is actually vastly different, as parallelizable problems >have a whole set of optimizations and advantages that generic concurrent >problems (especially those involving mutating state!) have a whole set >of race conditions that must be managed. > >__________________________________________________________________________ >OpenStack Development Mailing List (not for usage questions) >Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev