Hi list，
I am a learner of SLURM, now encountered one issue in the slurm19.05 version.
when I submit a job with 16 cores and 1 GPU, the job will be in PD state with
reason "Resources", which will impact the main scheduler to deal with lower
priority jobs(PD reason is Priority) in the same partit
Folks,
Tina made excellent points on why EPEL packaging SLURM is a good thing
and I am not going to re-iterate them.
Instead, I acknowledge Philip Kovacs positive contribution to those who
simply hoped for a "hassle free single node SLURM cluster to start with"
For some reasons [I do not unde
That is basically how I do it.
I created a local repository for the packages I build (slurm and any
other, like openmpi). This provides as much control as I could possibly
need/want. I can name them how I like to avoid conflict with any
external repositories.
I think it is a good idea to hav
I run into this problem occasionally. In my organization, most accounts
are created with tcsh as the default shell, and then users copy my bash
submission script example from my online documentation, or copy someone
else's submission script written in bash. And then when the job runs, it
fails
> ...I would say having SLURM rpms in EPEL could be very helpful for a lot of
> people.
>
> I get that this took you by surprise, but that's not a reason to not have
> them in the repository. I, for one, will happily test if they work for me,
> and if they do, that means that I can stop having
See below
On 1/25/2021 9:36 AM, Ole Holm Nielsen wrote:
On 1/25/21 2:59 PM, Andy Riebs wrote:
Several things to keep in mind...
1. Slurm, as a product undergoing frequent, incompatible revisions, is
not well-suited for provisioning from a stable public repository! On
the other hand, i
Sorry. I really don't want this to be a flame war, but...
...I would say having SLURM rpms in EPEL could be very helpful for a lot
of people.
I get that this took you by surprise, but that's not a reason to not
have them in the repository. I, for one, will happily test if they work
for me, a
I tried submitting jobs with --gres-flags=disable-binding but
this has not made any difference. Jobs asking for GPUs are still only
being run if a core defined in gres.conf for the GPU is free.
Basically seems the option is ignored.
-- Paul Raines (http://help.nmr.mgh.harvard.edu)
On Sun,
On 1/25/21 2:59 PM, Andy Riebs wrote:
Several things to keep in mind...
1. Slurm, as a product undergoing frequent, incompatible revisions, is
not well-suited for provisioning from a stable public repository! On
the other hand, it's just not that hard to build a stable version
where
Hi;
We are using the yumlock feature of the yum to protect unwanted upgrade
of the some packages. Also, Ole mentioned "exclude=slurm" option of the
repo file. It is not a solutionless problem. But, the package maintainer
is a valued resource which hard to find.
Regards,
Ahmet M.
25.01.202
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
Several things to keep in mind...
1. Slurm, as a product undergoing frequent, incompatible revisions, is
not well-suited for provisioning from a stable public repository! On
the other hand, it's just not that hard to build a stable version
where you can directly control the upgrade timin
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
13 matches
Mail list logo
