Hi Sourabh,

sourabh shinde <[email protected]> writes:

> Re: [slurm-dev] Re: Multifactor Priority Plugin for Small clusters 
>
> Thank you guys for your reply. 
>
> @Loris : Yes, i had a look at Gang Scheduling which does not fits my
> requirements.  In my case, a job which is scheduled should complete
> its execution and then the next job should start. this is what i need.
>
> @Chris : I had already set up accounting. but the resource limits was
> new. I have set limits on QOS and Users now, constraints are working
> well.
>
> @Ole : Wiki page was really helpful. :)
>
> Also, does modifying the mult-ifactor logic would really help in my
> case ?  if Not, what else can i do in order to go atleast close to
> what i need to achieve(the example referring in my previous post) ?

You may need to rethink what you are trying to achieve.  You seem to
expect that the priority of a job intrinsically has something to do
with the resources allocated the job.  This may be the case if you
define your factors appropriately, but primarily the two are not
connected and the priority just determines which order jobs should be
started in at a given point in time.

From your example, what you seem to want is that three users, each with
a different degree of what I'll call "importance" can all start jobs at
the same time, but, depending on the amount of "importance", they can
use different numbers of nodes.  With multifactor fairshare, the
priorities would have to be essentially equal and you would have to
restrict the number of nodes for the different degrees of "importance".
This brings with it other problems, such as what happens if only the
user with the lowest "importance" has jobs in the queue.  Can he or she
use all the nodes, or do some remain idle in case a more "important" job
comes along?  

I think if you and your users can accept the idea of fairshare over a
period rather than at every point in time, you might save yourself a
great deal of time and trouble with Slurm.

Regards

Loris

> Thanks and Regards
> Sourabh 
>
> Regards,
> Sourabh Shinde
> +49 176 4569 5546
> sourabhshinde.cf
>
> On Mon, Jul 3, 2017 at 8:02 AM, Loris Bennett <[email protected]> 
> wrote:
>
>  Hi Sourabh,
>
>  sourabh shinde <[email protected]> writes:
>
>  > Multifactor Priority Plugin for Small clusters
>  >
>  > Hello Everyone,
>  >
>  > I am new to SLURM and trying to run it locally on my PC. I am using
>  > Multifactor plugin to assign priorities for the job. The problem is
>  > multi factor doesn’t work as needed on small clusters. I tried
>  > assigning weightage to the factors as per my need but the scheduler
>  > always schedule the job on FIFO basis.
>  >
>  > I am trying to find some alternative where making changes to the
>  > priority plugin code could make it work on small clusters.
>  >
>  > for e.g
>  >
>  > If I have 12 nodes on my cluster, and if 3 users A,B and C with QOS
>  > low, normal and high respectively submit their job for execution. I
>  > want that SLURM should assign not all nodes to the User A. Atleast 1
>  > node should be assigned to the users B and C which are having low and
>  > normal priority. how can I achieve this ?
>  >
>  > PS: Gang scheduling and preemption are not possible in my case.
>  >
>  > Any help would be appreciated.
>  >
>  > Thanks in advance.
>  >
>  > Regards,
>  > Sourabh Shinde
>
>  I don't think you can achieve what you want with Fairshare and
>  Multifactor Priority. Fairshare looks at distributing resources fairly
>  between users over a *period* of time. At any *point* in time it is
>  perfectly possible for all the resources to be allocated to one user.
>  It is only over time that the allocation of resources will average out
>  to correspond to how you have configured the shares.
>
>  If you only have a small amount of resources and a small number of
>  users, this may not work very well. Have you looked at Gang scheduling
>  without premption?
>
>  Cheers,
>
>  Loris
>
>  --
>  Dr. Loris Bennett (Mr.)
>  ZEDAT, Freie Universität Berlin Email [email protected]
>
>

-- 
Dr. Loris Bennett (Mr.)
ZEDAT, Freie Universität Berlin         Email [email protected]

Reply via email to