Как планирование гетерогенной многопроцессорной обработки (HMP) реализовано в ядре Linux (Samsung Exynos5422)?
Кто-нибудь знает, как планирование гетерогенной многопроцессорной обработки (HMP) реализовано в планировщике ядра Linux?
Это было реализовано в ядре, поставляемом с платой ODROID-XU3. ( https://github.com/hardkernel/linux.git%20-b%20odroidxu3-3.10.y-android)
Я примерно знаю, что он вычисляет нагрузку на определенный процесс и на основе этой нагрузки перенесет на более быстрый или медленный процессор. Я ищу более подробное объяснение и, если возможно, расположение кода функций, которые реализуют эту функцию.
1 ответ
Код:
Оформить заказ под исходным кодом #ifdef CONFIG_SCHED_HMP в основном в kernel/sched/core.c
Краткий обзор (не очень):
Процессоры big.LITTLE можно настроить в 2 режимах работы:
- IKS - в ядре коммутатора (также известный как миграция процессора)
- GTS - Глобальное планирование задач (также известное как big.LITTLE MP)
GTS является гетерогенной формой работы, т. Е. HMP.
На самом абстрактном уровне HMP в настоящее время поддерживается простым расширением балансировки нагрузки DVFS и SMP. Оба из них полностью осведомлены о преимуществах производительности больших ядер (по сравнению с ядрами LITTLE) и соответственно планируют высокоприоритетные, ресурсоемкие задачи переднего плана.
Динамическое масштабирование напряжения и частоты (DVFS) используется для адаптации к мгновенным изменениям требуемой производительности. Режимы миграции big.LITTLE расширяют эту концепцию, позволяя переходить на "большие" ядра ЦП выше наивысшей рабочей точки DVFS ядер LITTLE. Миграция занимает около 30 микросекунд. Напротив, драйвер DVFS оценивает производительность ОС и отдельных ядер, как правило, каждые 50 миллисекунд, хотя в некоторых реализациях выборка выполняется несколько чаще. Изменение напряжения и частоты занимает около 100 микросекунд. Поскольку время, затрачиваемое на миграцию ЦП или кластера, меньше времени изменения DVFS и на порядок меньше периода оценки ОС для изменений DVFS, переходы big.LITTLE позволят процессорам работать с более низкими рабочими точками, чаще и, кроме того, быть полностью невидимым для пользователя.
В модели глобального планирования задач механизмы DVFS все еще работают, но планировщик ядра операционной системы знает о больших и LITTLE-ядрах в системе и стремится сбалансировать нагрузку высокопроизводительных потоков на высокопроизводительные ядра, а также низкую производительность или объем памяти. связанные потоки к сердечникам высокой эффективности. Это похоже на балансировщики нагрузки SMP сегодня, которые автоматически балансируют потоки между ядрами, доступными в системе, и не используют неиспользуемые ядра. В глобальном планировании задач big.LITTLE используется тот же механизм, но ОС отслеживает историю загрузки каждого потока и использует эту историю плюс выборку производительности в реальном времени для надлежащего баланса потоков между большими ядрами и ядрами LITTLE.
Ссылка: community.arm.com: десять вещей, которые нужно знать о big.LITTLE