Почему мы добавляем P, а не просто меняем M в планировщике Go? - PullRequest
0 голосов
/ 02 марта 2020

Как мы знаем, с Go 1.0 до Go 1.1, наиболее важным улучшением планировщика Go является добавление P в GM для создания GPM. Мы можем видеть, что оригинальный дизайн делает c там Масштабируемый Go Дизайн планировщика Делает c

Я запутался, почему мы добавляем P для хранения локальных runq и mcache, а не просто положить эти вещи на М. Как говорится, «Если не нужно, то существенность не будет добавлена». Очевидно, что первый добавляет сущность, а второй нет.

Почему мы выбираем первую?

1 Ответ

1 голос
/ 02 марта 2020

Я почти уверен, что «если не нужно, то существенность не будет добавлена» - это не поговорка; однако я считаю, что это вариант бритвы Оккама: не надо излишне умножать сущности. Тем не менее, «P (процессоры)» не являются лишними понятиями, когда речь идет о планировании процессов - если вам не хватает какой-либо концепции, соответствующей базовому оборудованию, на котором выполняются процессы (кроме максимального числа процессоров и числа свободных), тогда ваше планирование на самом деле слишком абстрактно. Я не являюсь экспертом в планировщике Go, и есть несколько проблемных элементов c, идентифицированных в связанном с ним документе, но суть улучшения, похоже, связана с реализацией "кражи работы", в результате чего простаивает P попробуй украсть ждущий Gs у других Ps. Это эффективно, потому что P знает, когда он становится бездействующим, тогда как M сам по себе не имеет представления о незанятом оборудовании.

...