[ 
https://issues.apache.org/jira/browse/YUNIKORN-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17720232#comment-17720232
 ] 

Peter Bacsko commented on YUNIKORN-1378:
----------------------------------------

I think one thing that seems viable is to check which predicates failed when we 
tried to allocate on a node. For reservation, we run only a subset of 
predicates, so we already have the results for reservation check. The delay 
between the two is very small, both happens inside {{Application.tryNodes()}}. 
We simply don't update {{nodeToReserve}} and {{scoreReserved}} if it's a 
reservation predicate.

Something like:
{noformat}
alloc, failedPreds := sa.tryNode(node, ask)

...

if allowReserve && askAge > reservationDelay && 
containsReservationPredicate(failedPreds) {
...
}

if nodeToReserve != nil && !nodeToReserve.IsReserved() {
                log.Logger().Debug("found candidate node for app reservation",
                        zap.String("appID", sa.ApplicationID),
                        zap.String("nodeID", nodeToReserve.NodeID),
                        zap.String("allocationKey", allocKey),
                        zap.Int("reservations", len(reservedAsks)),
                        zap.Int32("pendingRepeats", ask.GetPendingAskRepeat()))
                // skip the node if conditions can not be satisfied
               // <--- remove this ---->
                if !nodeToReserve.preReserveConditions(ask) {
                        return nil
                }
                // return reservation allocation and mark it as a reservation
                alloc := newReservedAllocation(Reserved, nodeToReserve.NodeID, 
ask)
                return alloc
        }
...
{noformat}

This requires interface changes between the shim and core. Another approach is 
to save this inside the shim and put an expiration date on them like 100ms or 
500ms whatever. But in this case, we have to make sure that these temporary 
entries are properly removed. Essentially we save this to a single 
{{map[*v1.Pod]PluginResults}} or multiple per-plugin/pre-phase 
{{map[*v1.Pod]bool}} maps and retrieve results from these as longs as they're 
considered recent enough.

Both has pros and cons, but the idea is that within a small time window, we 
don't run plugin code again.

> Add predicate with equivalence cache to improve the scheduler performance
> -------------------------------------------------------------------------
>
>                 Key: YUNIKORN-1378
>                 URL: https://issues.apache.org/jira/browse/YUNIKORN-1378
>             Project: Apache YuniKorn
>          Issue Type: Sub-task
>          Components: shim - kubernetes
>            Reporter: Qi Zhu
>            Assignee: Qi Zhu
>            Priority: Major
>              Labels: pull-request-available
>
> Now we call Filter every time when we predicate, we can cache some operations 
> for predicate so that we can improve the scheduler performance.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to