[slurm-users] Multifactor fair-share with single account

[Kamil Wilczek]

W dniu 4.01.2024 o 07:56, Loris Bennett pisze:
> Hi Kamil,
> 
> Kamil Wilczek <kmwil at mimuw.edu.pl> writes:
> 
>> Dear All,
>>
>> I have a question regarding the fair-share factor of the multifactor
>> priority algorithm. My current understanding is that the fair-share
>> makes sure that different *accounts* have a fair share of the
>> computational power.
>>
>> But what if my organisation structure is flat and I have only one
>> account where all my user reside. Is fair-share algorithm working
>> in this situation -- does it take into account users (associations)
>> from this single account, and tries to assing a fair-factor to each
>> user? Or each user from this account have the same fair-factor at
>> each iteration?
>>
>> And what if I have, say 3 accounts, but I do not wan't to calculate
>> fair-share between accounts, but between all associations from all
>> 3 accounts? In other words, is there a fair-share factor for
>> users/associations instead of accounts?
>>
>> Kind regards
> 
> We have a similar situation.  We do in fact have an account for each
> research group and the groups are associated with institutes and
> departments, but we use FairShare=parent so that all users are given the
> same number of shares and thus treated equally by the fair-share
> mechanism.
> 

Hi Loris,

but is the "FairShare=parent" still works for the Fair Tree, which is
the default algorithm since 19.05? I can find this option only for the
Classic Fair Share.

And I'm trying to differentiate between users, so that they are not
treated equally by the algorithm. Heavy users should have a lower
factor.

I think I could create an account for each user, but is that a common
practice and not an overkill?

I'm also trying to understand the Fair Tree, because there is a section
when it says that users can have different factors if their common
ancestor accounts have different factors. But what if they have only one
single common ancestor? Would then association/users still be sorted by
the fair-factor?

Kind regards,
-- 

> Cheers,
> 
> Loris
> 

-- 
Kamil Wilczek [https://keys.openpgp.org/]
[D415917E84B8DA5A60E853B6E676ED061316B69B]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <http://lists.schedmd.com/pipermail/slurm-users/attachments/20240104/7fb62388/attachment.sig>