Agreed. That's why I wanna generate a partition in the LLN type (I'll have a look at it) and keep it specially for non-parallel jobs.
Parallel jobs may go elsewhere (other partition grouping specific nodes). Does that make sense? On Thu, Nov 19, 2015 at 10:46 AM, <[email protected]> wrote: > > The downside is that parallel jobs would be spread across more nodes than > otherwise, decreasing application performance. > > > Quoting cips bmkg <[email protected]>: > >> Hi, >> >> If you generate a lot of mono-core sequential tasks, the regular SLURM >> allocation would pile them up into the first node, following with second , >> etc... >> >> The last node would (almost) never be used. >> >> Hence the idea to make it automatically distributed across nodes, one job >> at a time. >> >> Cheers, >> >> Remi >> >> On Wed, Nov 18, 2015 at 6:38 PM, Daniel Letai <[email protected]> wrote: >> >> I'm curious - what would be he point of such scheduling? >>> I tried to think about a scenario in which such a setting would gain me >>> anything significant and came up with nothing. What is the advantage of >>> this distribution? >>> >>> On 11/18/2015 08:37 AM, cips bmkg wrote: >>> >>> >>> ---------- Forwarded message ---------- >>> From: cips bmkg <[email protected]> >>> Date: Wed, Nov 18, 2015 at 12:11 PM >>> Subject: SLURM : how to have a round-robin across nodes based on load >>> average? >>> To: [email protected] >>> >>> >>> Hi, >>> >>> As a former user of SGE, I was used to SGE distributing jobs to nodes >>> that >>> had not been used recently (based on load average). >>> >>> I can see that the round robin distribution is only done for intra >>> node... >>> while an inter-node setting would probably have gotten me what I want. >>> >>> Can anyone advice how to set it up? >>> >>> thanks >>> >>> >>> >>> >>> >
