erius/shad-go
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

update README.md for smartsched

Browse source
This commit is contained in:
Pavel Danilov 2022-04-07 11:39:26 +00:00 committed by Fedor Korotkiy
parent a9f3a568e4
commit dd1c82f1cf
1 changed files with 21 additions and 8 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

29
distbuild/pkg/scheduler/README.md
View file

@ -36,20 +36,33 @@
Ожидающий исполнения джоб всегда находится в первой локальной очереди воркеров, на которых есть
результаты работы этого джоба.
Если джоб ждёт выполнения дольше `CacheTimeout` или если в момент `SchedulerJob` джоба не было в кеше ни на одном
из воркеров, то он попадает во все вторые локальные очереди воркеров, на которых есть хотя бы один артефакт
из множества зависимостей этого джоба.
Если выполнено одно из следующих условий, то джоб попадает во все вторые локальные очереди воркеров, на которых есть
хотя бы один артефакт из множества зависимостей этого джоба:
1) В момент вызова `ScheduleJob` джоба не было в кеше ни на одном из воркеров
2) Джоб ждёт выполнения дольше `CacheTimeout`
Определения первой и второй локальной очереди не зависят от того, в каком порядке в шедулер пришли джобы
и информация о кеше артефактов. То есть, если джоб уже находится в глобальной очереди и в этот момент приходит
информация, что этот джоб находится в кеше на воркере `W0`, то джоб должен быть добавлен
в первую локальную очередь `W0`.
информация, что этот джоб находится в кеше на воркере w<sub>0</sub>, то джоб должен быть добавлен
в первую локальную очередь w<sub>0</sub>.
Если джоб ждёт выполнения дольше `DepTimeout`, то он помещается в глобальную очередь.
Если джоб ждёт выполнения дольше `DepsTimeout`, то он помещается в глобальную очередь. Отсчет этого таймаута начинается
уже после обработки предыдущего условия, то есть не нужно вычитать из `DepsTimeout` никакое другое число.
## Тестирование
Вместо реального времени, юниттесты шедулера используют библиотеку `clockwork`. Это накладывает ограничения
на детали вашей реализации. Ожидание `CacheTimeout` и `DepTimeout` должно быть реализовано как `select {}` на
канале, который вернула функция `TimeAfter`. Мы считаем, что `CacheTimeout < DepTimeout`, и ожидание этих
таймаутов происходит последовательно в одной горутине.
канале, который вернула функция `TimeAfter`. Мы считаем, что `CacheTimeout < DepsTimeout`, и ожидание этих
таймаутов происходит отдельно в двух разных вызовах `select {}`:
```
select {
case <-TimeAfter(timeout):
...
...
}
```
Среди двух условий попадания во вторые локальные очереди, если выполнено первое из них, делать ожидание `CacheTimeout`
через `select {}` не нужно, иначе ваша реализация может проходить тесты с недетерминированным исходом.