Ticket 1540

Summary: -mblock:block allocates cores in reverse order
Product: Slurm Reporter: Brian Christiansen <brian>
Component: SchedulingAssignee: Moe Jette <jette>
Status: RESOLVED FIXED QA Contact:
Severity: 4 - Minor Issue    
Priority: --- CC: brian, da
Version: 14.11.4   
Hardware: Linux   
OS: Linux   
Site: SchedMD Slinky Site: ---
Alineos Sites: --- Atos/Eviden Sites: ---
Confidential Site: --- Coreweave sites: ---
Cray Sites: --- DS9 clusters: ---
Google sites: --- HPCnow Sites: ---
HPE Sites: --- IBM Sites: ---
NOAA SIte: --- NoveTech Sites: ---
Nvidia HWinf-CS Sites: --- OCF Sites: ---
Recursion Pharma Sites: --- SFW Sites: ---
SNIC sites: --- Tzag Elita Sites: ---
Linux Distro: --- Machine Name:
CLE Version: Version Fixed: 14.11.5
Target Release: --- DevPrio: ---
Emory-Cloud Sites: ---

Description Brian Christiansen 2015-03-17 08:49:47 MDT 
Bug 1523 points out that when using -mblock:block cores are allocated from highest to lowest which is different when using cyclic. I've traced this to _block_sync_core_bitmap (line 596 in 14.11) and commit dc5925f1.

Here are several relevant comments:

/* search for the best socket, */
/* starting from the last one to let more room */
/* in the first one for system usage */
...
/* select socket cores from last to first */
/* socket[0]:Core[0] would be the last one */

Is this still needed to allocate from the last to the first? Would it work to allocate first to last be more consistent?
Comment 1 Moe Jette 2015-03-18 06:45:00 MDT 
Looking through the patch, its goal appears to be packing resource allocations on the sockets. I'm really not sure why it's packing from highest to lowest rather than the reverse order, as for cyclic. Arguably it would be best to have consistency. Fixing this probably just requires changing the "for" loop arguments in a couple of places. Do you want me to pursue this or did you already work on the code?
Comment 2 Brian Christiansen 2015-03-18 06:48:18 MDT 
I haven't done any work on it. Go ahead an work on it.