-----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-----

Reply via email to