Ticket 1540 - -mblock:block allocates cores in reverse order
Summary: -mblock:block allocates cores in reverse order
Status: RESOLVED FIXED
Alias: None
Product: Slurm
Classification: Unclassified
Component: Scheduling (show other tickets)
Version: 14.11.4
Hardware: Linux Linux
: 4 - Minor Issue
Assignee: Moe Jette
QA Contact:
URL:
Depends on:
Blocks:
 
Reported: 2015-03-17 08:49 MDT by Brian Christiansen
Modified: 2015-03-18 10:48 MDT (History)
2 users (show)

See Also:
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: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this ticket.
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.