Preemption only occurs when there are no free licenses. During preemption, a project releases a borrowed license to the project that owns the license (and now has demand).
Jobs using licenses that support job suspension release their tokens and automatically resume from where they were suspended. Jobs using licenses that do not support suspension are killed and restarted from the beginning.
Depending on how your projects are set up (whether they are all at the same level or not), your preemption is either flat or hierarchical.
When preemption occurs, License Scheduler calculates token usage for each project. The calculation considers tokens in use, tokens required, and token ownership value.
Based on the token usage, License Scheduler determines the projects that require tokens, and those that have too many.
If project PRIORITY is configured in the Project section, the sort order of projects is based on priority, where a higher priority project is preempted last.
If ENABLE_MINJOB_PREEMPTION=Y, the number of preempted jobs is minimized. Projects with extra tokens are sorted by PRIORITY (if configured) or fairshare. The jobs are then sorted by RUSAGE.
Jobs with higher RUSAGE are preempted first to minimize the number of jobs preempted.
This setting is used in addition to basic preemption or PRIORITY.
When project groups are configured, introducing a hierarchy into the project configuration, hierachical preemption applies.
In top-down preemption, if P8 needs a token, it preempts from P1, P2, or P3 (who are more distant relations), not from P6 or P7 (siblings of P8).