Il 29/01/21 08:47, Diego Zuccato ha scritto:
>> Jobs submitted with sbatch cannot run on multiple partitions. The job
>> will be submitted to the partition where it can start first. (from
>> sbatch reference)
> Did I misunderstand or heterogeneous jobs can workaround this limitation?
My quick test
Il 25/01/21 14:46, Durai Arasan ha scritto:
> Jobs submitted with sbatch cannot run on multiple partitions. The job
> will be submitted to the partition where it can start first. (from
> sbatch reference)
Did I misunderstand or heterogeneous jobs can workaround this limitation?
--
Diego Zuccato
Hi,
Right, I understand this, what I’m describing is:
If a job is submitted to multiple partitions, -p part1, part2...
When the required resources in a partition (where the job can run) become
available, I’d expect the job to be dispatched to the partition with the
correct association(qos and
Hi,
Jobs submitted with sbatch cannot run on multiple partitions. The job will
be submitted to the partition where it can start first. (from sbatch
reference)
Best,
Durai
On Sat, Jan 23, 2021 at 6:50 AM Nizar Abed wrote:
> Hi list,
>
> I’m trying to enforce limits based on associations, but be
Hi list,
I’m trying to enforce limits based on associations, but behavior is not as
expected.
In slurm.conf:
AccountingStorageEnforce=associations,limit,qos
Two partitions:
part1.q
part2.q
One user:
user1
One QOS:
qos1
MaxJobsPU is not set
I’d like to have an association for user 1 for each
