Great work tracking this down and sending the patch. This logic is correct and will be in v2.5.1 when released.
Thanks! Quoting Chris Read <[email protected]>: > I took another look at the code, and the following patch restores the old > behaviour (in our case at least): > > diff -ur slurm-2.5.0/src/slurmctld/job_scheduler.c > slurm-2.5.0-prio-patch/src/slurmctld/job_scheduler.c > --- slurm-2.5.0/src/slurmctld/job_scheduler.c 2012-12-06 18:11:25.000000000 > -0600 > +++ slurm-2.5.0-prio-patch/src/slurmctld/job_scheduler.c 2012-12-14 > 09:29:58.928431693 -0600 > @@ -668,18 +668,21 @@ > if (sched_update != slurmctld_conf.last_update) { > char *sched_params, *tmp_ptr; > char *sched_type = slurm_get_sched_type(); > + char *prio_type = slurm_get_priority_type(); > #ifdef HAVE_BG > /* On BlueGene, do FIFO only with sched/backfill */ > if (strcmp(sched_type, "sched/backfill") == 0) > backfill_sched = true; > #endif > - if (strcmp(sched_type, "sched/builtin") == 0) > + if ((strcmp(sched_type, "sched/builtin") == 0) && > + (strcmp(prio_type, "priority/basic") == 0)) > fifo_sched = true; > /* Disable avoiding of fragmentation with sched/wiki */ > if ((strcmp(sched_type, "sched/wiki") == 0) || > (strcmp(sched_type, "sched/wiki2") == 0)) > wiki_sched = true; > xfree(sched_type); > + xfree(prio_type); > > sched_params = slurm_get_sched_params(); > if (sched_params && > > > > On Fri, Dec 14, 2012 at 3:00 PM, Chris Read <[email protected]> wrote: > >> Greetings all... >> >> It looks to me like changes to the scheduler in 2.5.0 have broken >> priority/multifactor. I've run a sample test load through versions 2.4.3 >> (what we currently have in production), 2.4.5 and 2.5.0. All three versions >> adjust the priority of the jobs as I expect (confirmed by sprio -l) but >> 2.5.0 ignores the priority value only allocates the jobs in the order they >> were submitted (FIFO) while the 2.4.x builds allocate them by priority. >> >> I've had a brief look at the code, and if feels to me like the changes to >> the main loop in schedule() in job_scheduler.c is possibly to blame, but my >> C is so rusty I'm not sure where I should start trying to fix it... >> >> Chris >> >> >> >
