+1 Generally people have in mind the efficient use of resources when they think of virtualization. Thus I would be in favor of sorting in ascending order as that will approximate best fit and hence give better resource utilization.
Mark On Mon, Feb 18, 2013 at 10:55 AM, Aaron Coburn <[email protected]> wrote: > +1 > > I also like this idea. Making this a configurable option makes sense -- it > would be nice to have the default set to ascending order as you describe. > > Aaron C > > > On Feb 18, 2013, at 10:42 AM, Aaron Peeler <[email protected]> > wrote: > >> I would like this ability, it would definitely simplify the mappings. >> >> I think it should be applied to both # or procs. and memory. >> >> I'm fine with either approach to just reserve it so it matches the min >> valus or to have an option to choose which method. >> >> Aaron >> >> On Mon, Feb 18, 2013 at 10:31 AM, Josh Thompson <[email protected]> >> wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Hi all, >>> >>> I'd like to get people's thoughts about reversing how computers are assigned >>> for reservations relative to the specified amount of RAM for an image. >>> Currently, the scheduler builds a list of computers that can fulfill a given >>> reservation and orders them by specs of the machine by this priority: >>> >>> first by procspeed * proc number >>> next by amount of RAM, >>> finally by network speed >>> >>> Each of those is ordered in a descending order (i.e. best specs at the top). >>> Then, the highest rated machine is given to the user. >>> >>> That algorithm came from our initial design back in 2004 when our nodes >>> didn't >>> have lots of RAM, didn't have a high variability of contained RAM, didn't >>> have >>> more RAM that some of the OSes could handle, and we weren't doing any >>> virtualization. The idea was that the user would get the best available >>> machine for the reservation. >>> >>> Now, with nodes having very high amounts of RAM, a high variability of >>> contained RAM, and having WinXP images that can't even use more than 4 GB of >>> RAM, I'm wondering if ordering for RAM (and maybe all specs) should be >>> reversed. This would make it so that priority is given to assign a node >>> that >>> just meets the specs for the image rather than assigning the best one >>> available. We're running in to cases where we have some bare metal nodes >>> with >>> 24 GB or more of RAM, but still have WinXP images available to users. We >>> have >>> to map things so that the WinXP images cannot get deployed to the higher RAM >>> nodes to keep from wasting the RAM when other users would like to have it. >>> Things would be simplified if we could just have a more general pool and >>> have >>> the scheduler take care of keeping resources from being wasted. >>> >>> What do others think? I could also make it an option in conf.php as to >>> which >>> method is used. However, unless people feel it useful to keep the current >>> method, it would be simpler to just reverse the ordering. Also, if you >>> think >>> it is a good idea to reverse it, should all specs be reversed, or just RAM? >>> >>> Thanks, >>> Josh >>> - -- >>> - ------------------------------- >>> Josh Thompson >>> VCL Developer >>> North Carolina State University >>> >>> my GPG/PGP key can be found at pgp.mit.edu >>> >>> All electronic mail messages in connection with State business which >>> are sent to or received by this account are subject to the NC Public >>> Records Law and may be disclosed to third parties. >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v2.0.19 (GNU/Linux) >>> >>> iEYEARECAAYFAlEiSTwACgkQV/LQcNdtPQN3qQCeLaxbUg9Rh6F4mpQrcn1mh5jz >>> VSEAn2C35CQCIqLnRUJFansQ5zKIhlNa >>> =KVAL >>> -----END PGP SIGNATURE----- >>> >> >> >> >> -- >> Aaron Peeler >> Program Manager >> Virtual Computing Lab >> NC State University >> >> All electronic mail messages in connection with State business which >> are sent to or received by this account are subject to the NC Public >> Records Law and may be disclosed to third parties. > -- Mark Gardner --
