[
https://issues.apache.org/jira/browse/YUNIKORN-3353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Richardson updated YUNIKORN-3353:
--------------------------------------
Description:
{{sortedRequests}} is ordered by priority, then age. Whether an ask is
allocated plays no part in that ordering, so allocated and pending asks sit
side by side in the list. {{tryAllocate}} walks it from the front, skipping the
allocated ones with
{code:java}
if request.IsAllocated() { continue }{code}
which means a read lock each. The more asks an application has already had
satisfied, the more there are to skip, so each scheduling cycle costs more than
the last. In a CPU profile of master that skip is 18% of
{{{}Application.tryAllocate{}}}.
Keep the slice pending-only instead: {{allocateAsk}} removes the ask,
{{deallocateAsk}} puts it back. The container and its insert algorithm are
unchanged — only membership changes.
was:
{{sortedRequests}} is ordered by priority, then age. Whether an ask is
allocated plays no part in that ordering, so allocated and pending asks sit
side by side in the list. {{tryAllocate}} walks it from the front, skipping the
allocated ones with {{if request.IsAllocated() \{ continue }}} — a read lock
each. The more asks an application has already had satisfied, the more there
are to skip, so each scheduling cycle costs more than the last. In a CPU
profile of master that skip is 18% of
{{{}Application.tryAllocate{}}}.
Keep the slice pending-only instead: {{allocateAsk}} removes the ask,
{{deallocateAsk}} puts it back. The container and its insert algorithm are
unchanged — only membership changes.
> Keep only pending asks in sortedRequests
> ----------------------------------------
>
> Key: YUNIKORN-3353
> URL: https://issues.apache.org/jira/browse/YUNIKORN-3353
> Project: Apache YuniKorn
> Issue Type: Sub-task
> Components: core - scheduler
> Reporter: Dale Richardson
> Assignee: Dale Richardson
> Priority: Major
>
> {{sortedRequests}} is ordered by priority, then age. Whether an ask is
> allocated plays no part in that ordering, so allocated and pending asks sit
> side by side in the list. {{tryAllocate}} walks it from the front, skipping
> the allocated ones with
> {code:java}
> if request.IsAllocated() { continue }{code}
> which means a read lock each. The more asks an application has already had
> satisfied, the more there are to skip, so each scheduling cycle costs more
> than the last. In a CPU profile of master that skip is 18% of
> {{{}Application.tryAllocate{}}}.
> Keep the slice pending-only instead: {{allocateAsk}} removes the ask,
> {{deallocateAsk}} puts it back. The container and its insert algorithm are
> unchanged — only membership changes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
