openstack team mailing list archive

[Martinx - ジェームズ <thiagocmartinsc@xxxxxxxxx>]

I have an idea for the scheduler improvement!!

Since Linux have a new feature called "Kernel SamePage Merging (KSM)",
which reduces the amount of RAM used by identical KVM Instances, the
Openstack scheduler MUST take this into account.

It is simple:

* Start identical images on the same hypervisor (as possible).

This will reduce the amount of RAM of our entire cloud environment.

What do you guys think about it?

Cheers!
Thiago

On 3 January 2013 16:48, Joseph Suh <jsuh@xxxxxxx> wrote:

> Phil,
>
> I agree with the suggestion. We wanted to instantiate a set of VMs whose
> hosts are located close each other. The current scheduler could not handle
> this use case since it needed to return "optimal" set of hosts at the same
> time. The first "optimal" host returned by the current scheduler may not be
> a part of the set of "optimal" hosts. We worked on the scheduler a little
> (in draft mode), and if you are interested in it, please let me know.
>
> Thanks,
>
> Joseph
>
> ----- Original Message -----
> From: "Vishvananda Ishaya" <vishvananda@xxxxxxxxx>
> To: "Phil Day" <philip.day@xxxxxx>
> Cc: "openstack@xxxxxxxxxxxxxxxxxxx (openstack@xxxxxxxxxxxxxxxxxxx) (
> openstack@xxxxxxxxxxxxxxxxxxx)" <openstack@xxxxxxxxxxxxxxxxxxx>
> Sent: Thursday, January 3, 2013 12:43:02 PM
> Subject: Re: [Openstack] Potential filter scheduler enhancement
>
>
> I think this seems reasonable, although FYI, openstack-dev seems like a
> better place for emails like this.
>
>
> Vish
>
>
>
> On Jan 3, 2013, at 6:40 AM, "Day, Phil" < philip.day@xxxxxx > wrote:
>
>
>
>
>
> Hi Folks, and Happy New Year.
>
> In working with the Filter Scheduler I’m considering an enhancement to
> make the final host selection stage configurable. Whilst its sometimes fine
> to just pick the first host from the list of weighted hosts, the more
> general case is that I’d like to be able to have the scheduler pick one of
> the first N hosts on the weighted list. The specific use cases that I have
> in mind are:
>
> - On a large system there is very rarely a single ideal / optimal host for
> a particular instance to be placed on. In practice any of the N most
> suitable hosts would be fine and allowing the scheduler to randomly pick
> one of these would add some spread for multiple requests that come in at
> the same time. (I know we now have the retry mechanism if a particular host
> can’t in fact handle a specific request – this is a complement to that
> rather an alternative). Of course anyone who wants to schedule to host in
> strict weighted order would be able to configure N to be 1 (or we could
> keep the current host selection method as a separate default)
>
> - When creating M instances in one request we could just put each onto one
> of the first M hosts in the list (since these have all been filtered as
> being suitable) instead of having to iterate through the filter / weighting
> functions for each successive instance.
>
> Based on this I’m thinking that such a host_selection function would
> replace the whole of the for loop at the end of the _schedule() method in
> filter_scheduler.py, and take as input the number of instances. The default
> function would of course be the current behaviour. Before going any further
> with this thinking I wanted to get input on:
>
> i) Do others recognise these use cases as being useful, and are there
> other similar use cases to be considered at the same time ?
>
> ii) Is it reasonable to make the filter scheduler configurable in this
> way, rather than creating a separate scheduler ? (My feeling is that
> because it would only be replacing ~10% of the current filter_scheduler
> code it would be better to not create a new scheduler)
>
> iii) Should the configuration logic for this new function be in the
> fliter_scheduler itself, or in the host_manager (which is where the filter
> and weighting functions are configured) ?
>
>
> Cheers,
> Phil
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>