[
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 {{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.
was:
{{sortedRequests}} holds every ask an application has, allocated or not, so
{{tryAllocate }}walks an ever growing prefix of already-allocated asks to reach
the first one that can still be scheduled — skipping each with {{{}if
request.IsAllocated() \{ continue }{}}}, and {{IsAllocated}} takes a read lock
per ask. 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 — {{sortedRequests}} was
already a sorted slice with the same binary-search insert, and the reason it is
a slice rather than a tree is documented in {{sorted_asks.go}} and still holds.
*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 {{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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
