[
https://issues.apache.org/jira/browse/YUNIKORN-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17791878#comment-17791878
]
Wilfred Spiegelenburg commented on YUNIKORN-2209:
-------------------------------------------------
The user tracker does use the boolean at the moment to decide whether to call
the group update or not. We need that functionality. If the user is denied we
do not want to go and check the group. That would be incorrect andÂ
I do agree that there is room for improvement: if we have found that the
wildcard is applicable why do we not set the quota in the queue tracker?
Because the quota in the queue tracker is not updated we do it over and over
again. If we set the quota it becomes a far easier resource comparison. We
should have done that way earlier in the headroom check. We always call the
headroom check before we schedule and create the queue tracker there if it does
not exist. That is the correct point to load the wildcard details.
If we would want to track/know that the quota came from the wildcard we can
track it in the queue tracker object. Might even help later in the config
changes.
We are also doing things multiple times, lots of clones and adds that can be
simplified. {{finalResourceUsage}} is build up with the temporary end result
and then we throw it away to do the calculation again if it all passes...
> Remove limit checks in QueueTracker
> -----------------------------------
>
> Key: YUNIKORN-2209
> URL: https://issues.apache.org/jira/browse/YUNIKORN-2209
> Project: Apache YuniKorn
> Issue Type: Sub-task
> Components: core - common
> Reporter: Peter Bacsko
> Assignee: Peter Bacsko
> Priority: Major
>
> {{QueueTracker.increaseTrackedResource()}} contains code that is no longer
> relevant and is a good candidate for removal.
> It verifies whether the increased resource is over certain limits. However,
> this is not the responsibility of the tracker, at least not anymore. The
> method returns a boolean which is no longer used by the application.
> Worse, we ignore the increment calculation but perform the decrement part.
> This results in a corrupted state. Even if we detect that limits are
> violated, there's no reason to mess things up even further.
> It also has performance impacts. Lot of intermediate Resource objects are
> created, eg. "finalResourceUsage", {{resources.NewResource()}} is called
> multiple times. These all results in heap allocations and they immediately
> become garbage as soon as the method returns. Actually after performing
> YUNIKORN-2201, {{Manager.IncreaseTrackedResource()}} is a 1.5-2% contributor
> to the overall heap and cpu usage. Not a massive save, but if it's easy to
> gain a quick improvement, let's go for it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
