[
https://issues.apache.org/jira/browse/YUNIKORN-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17796013#comment-17796013
]
Manikandan R commented on YUNIKORN-2209:
----------------------------------------
{quote}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.
{quote}
Raised PR to address this optimisation in scheduling cycle.
> 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
> Labels: pull-request-available
>
> {{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]
