Setting RealMemory and FastSchedule=2 is working for us. We don't have constrained job sizes so the examples I gave were just intended to be illustrative of counting and using whole numbers. The setup will also allow us to easily schedule 16 8GB jobs on a 128GB node (or 4*16+8*8 or ... as long as we do not care too much about socket locality).
We will probably use Gres for other properties but have not done so yet. I suppose this setting implies we should have our own check for memory failing and being disabled. We can work with that. Cheers, Gareth > -----Original Message----- > From: Franco Broi [mailto:[email protected]] > Sent: Monday, 22 December 2014 5:15 PM > To: slurm-dev > Subject: [slurm-dev] Re: rounding in memory scheduling - or overcommit > > > > Maybe you could use a Gres; > > 128GB machines could have Gres=M64,M128 > 512GB machines Gres=M64,M128,M512 > > When a user submits a job that only requires 64GB (--gres=M64), it will > go to any machine - using partition priority to assign smaller nodes > first. Another 64GB job cannot go to the same nodes. A 512GB job can > only go to the bigger memory machines. > > On Sun, 2014-12-21 at 21:11 -0800, Morris Jette wrote: > > If you set RealMemory high then you will also need to configure > > FastSchedule=2, but that also prevents Slurm from downing nodes with > > down CPUs or other hardware. -snip-
