Какой из них будет рабочей нагрузкой (использованием) ядра ЦП, если есть постоянный промах кеша, будет 100%?

То есть, если ядро ​​процессора большую часть времени ожидает данных из ОЗУ или кеша-L3 с кешем-промахом, но система работает в режиме реального времени (приоритет потока в реальном времени), а поток привязан (аффинити) к ядро и работает без переключения потока/контекста, какую нагрузку (использование) CPU-Core должен показывать на современном x86_64?

То есть загрузка ЦП отображается как уменьшение только при входе в систему Idle?

И если кто знает, отличается ли поведение в этом случае для других процессоров: ARM, Power[PC], Sparc?

Пояснение: показывает загрузку ЦП в стандартном диспетчере задач в ОС Windows.


person Alex    schedule 14.11.2013    source источник
comment
Вопрос не ясен - показывать где? какую программу используете для мониторинга? Вы можете легко обнаружить этот случай с помощью мониторов производительности (vtune, perf или любого другого инструмента профилирования).   -  person Leeor    schedule 14.11.2013
comment
@Леор Хорошо. Я добавил уточнение.   -  person Alex    schedule 14.11.2013
comment
Разве у него нет графика использования физической памяти (на вкладке производительности)? Это должно измерять ОЗУ, но время доступа к L3 имеет гораздо меньшую величину.   -  person Leeor    schedule 14.11.2013
comment
Ядро процессора со временем глохнет, это считается полной загрузкой.   -  person Hans Passant    schedule 14.11.2013
comment
@Ханс Пассант Спасибо! Если у вас или у кого-то есть более развернутый ответ, почему так происходит, и когда есть нагрузка (выполнение инструкций ЦП, ожидание промаха кеша, ...), а когда нет (Idle), то просьба написать ответ.   -  person Alex    schedule 14.11.2013
comment
@Leeor Меня интересует использование ЦП, потому что при промахе кеша ЦП не выполняет никаких ЦП-инструкций, и означает ли это, что ЦП находится в режиме ожидания?   -  person Alex    schedule 14.11.2013
comment
Поскольку большинство процессоров могут выполнять инструкции не по порядку, это обычно означает, что они имеют достаточно независимых доступов, которые могут выполняться параллельно. Один промах не означает, что весь ЦП останавливается, не говоря уже о том, чтобы простаивать.   -  person Leeor    schedule 15.11.2013
comment
@Leeor Но как насчет очень больших промахов, когда они занимают 90% процессорного времени, повлияет ли это на использование ЦП? ?   -  person Alex    schedule 15.11.2013


Ответы (2)


Аппаратный поток (логическое ядро), остановившийся из-за промаха кеша, не может делать ничего другого, поэтому он по-прежнему считается занятым для целей диспетчеров задач / учета времени ЦП / временных интервалов планировщика процессов ОС / тому подобное.

Это справедливо для всех архитектур.

Без гиперпоточности «аппаратный поток» / «логическое ядро» — это то же самое, что и «физическое ядро».

Morphcore / другое оперативное переключение между гиперпоточностью и более мощным одноядерным процессором может привести к разнице между потоком, который занимает много исполнительных блоков, и потоком, заблокированным в кеше, который пропускает большую часть времени.

person Peter Cordes    schedule 25.06.2015
comment
Я думаю, вы путаете то, что ОС показывает как использование ЦП, с более низкоуровневыми понятиями, такими как IPS, пропускная способность и задержка инструкций. - person ; 25.06.2015
comment
Благодарю вас! т.е. Intel x86_64, независимое виртуальное (логическое) или физическое (аппаратное) ядро, которое останавливается из-за промаха кеша, может показывать 100% загрузку ЦП в ОС. И верно ли это для гиперпоточности - когда первое логическое ядро ​​ожидает второго ядра (на том же аппаратном ядре), то первое логическое ядро ​​тоже показывает занятость? - person Alex; 25.06.2015
comment
@ knm241: Когда я говорю «остановлено», я имею в виду, что выполнение не по порядку останавливается, потому что в нем закончились инструкции, которых нет в цепочке зависимостей остановленной загрузки. Я указываю, что IPC/остановки конвейера/эффективность кода не влияют на то, считает ли ОС ядро ​​занятым. - person Peter Cordes; 25.06.2015
comment
@Alex: каждый аппаратный поток независим. При гиперпоточности каждое физическое ядро ​​имеет два аппаратных потока, также называемых логическими ядрами. Не бывает такого, чтобы первое ядро ​​ждало второе ядро. Одно ядро ​​может выполнять код, ожидающий снятия блокировки другим потоком, но это не одно и то же. (Обычное поведение блокировки состоит в том, чтобы сообщить ОС, что мы спим между проверками на свободную блокировку.) - person Peter Cordes; 26.06.2015
comment
@Peter Cordes Может быть, это мое непонимание Hyper Threading и это другой вопрос, но может ли одно логическое ядро ​​​​остановиться в ожидании освобождения аппаратных ресурсов (ALU, порты, ...) другого логического ядра, если они оба принадлежат к такое же физическое ядро? - person Alex; 26.06.2015
comment
Но я все равно не вижу ссылки со статистикой использования ОС. Использование ЦП ОС просто показывает, сколько времени ЦП тратит на выполнение кода пользовательского режима (и в контексте ядра) в единицу времени. ОС не измеряет использование ЦП, подсчитывая простои или что-то еще, это прозрачная архитектура. - person ; 26.06.2015
comment
@ knm241: Я думаю, вы видите разрыв между тем, как вы читали то, что я на самом деле написал, и тем, что я хотел сказать. Я добавил слово к своему ответу: все еще считается, чтобы было ясно, что ответ на вопрос ОП таков, как вы говорите: время, затраченное на выполнение пользовательского кода, - это потраченное время, независимо от того, сколько остановок этот код испытывает. - person Peter Cordes; 26.06.2015
comment
@Alex: процессоры Intel с гиперпоточностью конкурируют между собой, разделяя большинство ресурсов выполнения или разделяя их. Во внешнем интерфейсе кэш декодеров / uop чередует каждый цикл между потоками инструкций двух потоков, но затем логика OoO просто делает то, что она всегда делает, и запускает самые старые uop, у которых есть готовые операнды. Дополнительные сведения см. в документе microarch на сайте agner.org/optimize. Я не уверен, достаточно ли умен HT, чтобы распознать, что один поток остановлен (из-за промаха кеша или чего-то еще, а не с PAUSE insn), и использовать каждый цикл внешнего интерфейса в другом потоке. - person Peter Cordes; 26.06.2015
comment
Я написал ответ, чтобы лучше объяснить вам свою точку зрения, не могли бы вы прокомментировать его? Мне кажется, что, по аналогии, ОП спрашивает, следует ли считать время, потраченное на чтение документации для фреймворка, рабочим временем или свободным временем. Это может быть и то, и другое, где вы это делаете. То же самое и с киосками, они могут простаивать или заняты в зависимости от того, где они происходят. - person ; 26.06.2015

Я не вижу связи между статистикой использования ЦП ОС и оптимальным использованием конвейера. Я думаю, что они не коррелированы, так как ОС не измеряет загрузку конвейера.
Я пишу это в надежде, что Питер Кордес поможет мне лучше понять это, и в качестве продолжения комментариев.


Пользовательские программы очень часто передают управление ОС: когда им требуется ввод данных от пользователя или когда они заканчивают работу с сигналом/сообщением. Программа с графическим интерфейсом в основном представляет собой просто большие циклы, и на каждой итерации управление передается ОС до следующего сообщения. Когда ОС имеет контроль, она планирует другие потоки/задачи, и если не требуются другие действия, просто войдите в процесс бездействия (давным-давно замкнутый цикл, теперь состояние сна) до следующего прерывания. Это время простоя.

Время, затраченное ISR на обработку пользовательского ввода, считается временем простоя любой ОС. Промах кеша там еще считался бы простоем.

Тяжелой программе требуется больше времени, чтобы завершить работу с данным сообщением, тем самым возвращая управление ОС, скажем, 2 раза в секунду вместо 20. Использование ЦП (1000-20)/1000 = 98%.

Это не имеет ничего общего с оптимальным использованием архитектуры ЦП, поскольку указанные зависания могут возникать в коде ОС и по-прежнему быть частью статистики времени простоя. Загрузка ЦП на уровне конвейера не измеряется и ортогональна статистике ОС.

Использование ЦП предназначено для использования системным администратором, это мера нагрузки, которую вы оказываете на систему, а не мера того, насколько эффективно была сгенерирована сборка программы. Системные администраторы не могут помочь с этим, но измерение того, как часто ОС возвращала управление (без вытеснения), является мерой того, насколько программа загружает систему. И системные администраторы могут окончательно завершать тяжелые программы.

person Community    schedule 26.06.2015
comment
Вы правы в том, что оптимальное использование конвейера не коррелирует со статистикой использования ЦП ОС. Они ортогональны, как вы говорите. - person Peter Cordes; 27.06.2015
comment
Вы ошибаетесь, говоря, что время, проведенное в коде ядра (например, в подпрограммах обслуживания прерываний), считается простоем. Это не пользовательское время для этого процесса, а системное, а не простоя или время ожидания ввода-вывода. время простоя - это только тогда, когда ЦП фактически приостановлен в ожидании прерывания, а не тогда, когда он фактически обрабатывает прерывание от нажатия клавиши или движения мыши. Возможно, в некоторых из моих комментариев к моему ответу говорилось об учете времени для одного процесса (то есть только времени пользователя для него). Думаю, что-то вроде диспетчера задач Windows с диаграммами загрузки ЦП также подсчитывает системное время. - person Peter Cordes; 27.06.2015
comment
@PeterCordes хорошо, понял! Просто для завершения я подумал об этом: когда системный таймер запускает IRQ и процессор просыпается, ядро ​​​​должно обновить состояние алгоритма измерения, чтобы теперь оно измеряло системное время вместо времени простоя, а также сохраняло подсчитанное время простоя. . если промах кеша происходит до обновления состояния, это считается временем простоя. Верно? У вас случайно нет информации о том, как Linux измеряет это время? Спасибо! - person ; 27.06.2015
comment
Я не смотрел код Linux для этого. Я действительно не думал об этом раньше, но да, я думаю, ядру нужен учет процессорного времени при каждом сне и каждом пробуждении, и это может быть отложено из-за промаха кеша. Если только он не использует счетчики производительности ЦП для подсчета тактов без остановки или чего-то еще, вместо того, чтобы постоянно запускать и останавливать секундомер. - person Peter Cordes; 28.06.2015
comment
И еще одно: обслуживание прерываний никогда не происходит в том же потоке, что и пользовательский процесс. Процессы выполняют системные вызовы, и время, затраченное на код ядра от имени пользовательского процесса, идет на системное процессорное время этого процесса. Подпрограммы обслуживания прерываний — это общее время ЦП системы, но не учитываемое для какого-либо процесса. Когда процесс приостанавливается при вводе (например, системные вызовы select(2) / poll(2) Unix или вызов ожидания следующего окна-сообщения Windows), это не подпрограмма службы прерывания, которая доставляет сообщение напрямую. ISR обычно выполняет минимально возможную работу, а другой код ставит сообщение в очередь. - person Peter Cordes; 28.06.2015
comment
Я проверил, как Linux ведет учет средней нагрузки: git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/ объясняет, как это работает: каждое прерывание таймера , был прерван и соответственно ведет учет времени. (Это НАМНОГО эффективнее, чем rdtsc при каждом переключении контекста! Для учета времени процессора важнее быть легким, чем точным. В какой-то момент, я думаю, он сортирует простоя и io-wait. планировщик может выполнять собственное отслеживание выделения временных интервалов ЦП потокам, но loadavg является отдельным. - person Peter Cordes; 29.06.2015
comment
Спасибо @PeterCordes, я ценю ваши усилия - person ; 29.06.2015