Not tried to do resource sharing based on memory, most users don't really know how much memory their jobs will require and usually only find out once a jobs has failed. We use Gres to give users the option to limit the number of jobs per node based only on a simple, small, medium or large Gres.
On Mon, 2014-12-22 at 19:30 -0800, [email protected] wrote: > 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-
