Решил замеры провести. Что то странное получается.

VOLKOFF

> Когда окно выходит на первый план в клиентской системе, все потоки в процессе, содержащем тот поток, который владеет окном первого плана,получают утроенные кванты.

--> Link <--



Смысл замеров следующий. Поток крутится 1сек в цикле считая чис прерываний за это время, через их возврат сбросом RPL. По окончании времени выводит число прерываний и сново считает их за 1 сек. Если потоков несколько, то они одновременно и синхронно считают за 1 сек, атомарно инкрементируя счётчик. Таким образом увеличивается точность подсчёта, так как пока один тред спит, другой считает.

Использовано два способа NtSetTimerResolution и NtSetIntervalProfile. Первый сервис на стороне hal.HalSetTimeIncrement не перестраивает железо, изменяя лишь переменные, связанные с обработкой прерывания. Второй сервис на стороне hal.HalSetProfileInterval устанавливает значение счётчика APIC, который после обнуления счётчика вызывает прерывание. При этом он выключен и что бы его завести нужно вызвать NtStartProfile.

1th/16th число измеряющих потоков.
resol - вызван NtSetTimerResolution с минимальной точностью.
apic - запущен таймер с текущим разрешением или минимальным.

Красным подчёркнуто начало событий перетаскивания чужого окна мышью(другого процесса).

e607_10.01.2020_EXELAB.rU.tgz - ints.7z

-----
vx

| Сообщение посчитали полезным:

Если использование переменных квантов разрешено, индекс кванта процесса зависит от окна, если первый план, должен накинуть кванты
Индексы см в таблице PspForegroundQuantum\PspVariableQuantums
Какой процесс отнести к процессам первого плана, решает система управления окнами, в переменной PsPrioritySeparation отражается индекс таблицы квантов, используемый для выбора квантов потоков первого плана.
Владельцы окон также получают при пробуждении дополнительное повышение приоритета из-за активности при работе с окнами, смысл аналогичен - ап интерактива.

В "Windows Internals" есть примеры простых тестов этого дела, см:
EXPERIMENT: Watching foreground priority boosts and decays
EXPERIMENT: Watching priority boosts on GUI threads

| Сообщение посчитали полезным:

VOLKOFF

Почему тогда число прерываний растёт в моём апп при активности гуя в другом апп ??

По идеи наоборот из за укорачивания кванта число прерываний должно быть меньше

С таймером апик поведение потоков ожидаемо - число прерываний в единицу времени сильно возрастает. На последник трёх логах активность гуя не заметна.

А есчо почему сабж должен влиять на потребление энергии, если это софт. механизм ?

Можно попробовать получить число квантов в единицу времени SYSTEM_THREAD_INFORMATION.ContextSwitches; на запрос этого слепка уходит ~2кванта.

> EXPERIMENT

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

При высоком числе прерываний квантование не влияет на измерение. При малом числе прерываний происходит странное повышение I/s.

-----
vx

| Сообщение посчитали полезным:

VOLKOFF

Вы очень долго не отвечаете.

-----
vx

| Сообщение посчитали полезным:

difexacaw пишет:
Вы очень долго не отвечаете
Разве подобные риторические вопросы требуют ответов?

Был приведен тезис, который в книге на которую я сослался подтверждался простым пошаговым примером стандартными средствами ОС. Вы в свою очередь провели некий загадочный эксперимент используя самописный софт, который дал вам некий рандомный результат и хотите чтобы я написал причину почему так случилось.
Хмм... могу предложить погуглить Список универсальных ответов на любое "почему"

| Сообщение посчитали полезным: sefkrd

VOLKOFF

Но я так и не вижу объяснения по росту числа прерываний. А тесты не загадочные, а вполне грамотно реализованы. Могу сурки показать если нужно. Но врядле это вам чем то поможет.

Ты просто начитался какой то технической фигни а когда дело дошло до реальных измерений тупо слился. Если бы ты знал что ядро при обработки прерывания от часиков приводит к серии прерываний(софт реализация через настройку апик), то смог бы обьяснить. Но увы ты это не знаешь. Читай дальше умные книжки

-----
vx

| Сообщение посчитали полезным:

difexacaw пишет:
дро при обработки прерывания от часиков приводит к серии прерываний(
А какой тогда смысл что-то мерить? По сути ты измеряешь производительность проца когда его дергают за ножку, а не частоту интераптов таймера или hpet

Добавлено спустя 6 минут
difexacaw пишет:
Поток крутится 1сек в цикле считая чис прерываний за это время, через их возврат сбросом RPL.
Так себе способ. Есть гарантия, что поток всегда крутится на одном ядре?

| Сообщение посчитали полезным:

spinz

> а не частоту интераптов таймера

Именно частоту прерываний. Это работает так - устанавливается RPL при нулевом селекторе: mov r,3/mov es,r. После прерывания процик обнуляет селектор при iret. Для чистоты эксперимента используется XP, так как во первых по большей части есть сурки ядра, а во вторых на wow будет шум(ядро фиксит селекторы).



- способ отличный, это прямое измерение.

> поток всегда крутится на одном ядре?

На двух процах.

-----
vx

| Сообщение посчитали полезным:

Есть уверенность в том, что ты выставляешь rpl и читаешь его на том же ядре?

| Сообщение посчитали полезным:

spinz

А какая разница на каком, селектор сбросится после прерывания, так же если произойдёт переключение на другой проц. Так как это никакого значения не имеет для теста, то я не устанавливал аффинитет, крутится на двух. Попытка исполнять на одном не влияет на тест.

-----
vx

| Сообщение посчитали полезным:

Вот смотри. Ты выставил в селекторе рпл=03. И ждешь когда он изменится. Планировщик отдал поток другому ядру. И ты будешь считать, при изменении рпл, что произошел интерапт. Не учитывая смену контекста

| Сообщение посчитали полезным:

spinz

Контекст и переключается при прерывании, поэтому маска affinity и не оказывает никакого эффекта. Планировщик загрузит в другой процессор rpl и он сбросится при возврате.

Есть мысли почему растёт число, когда сокращается квант ?

-----
vx

| Сообщение посчитали полезным:

Блять, так переключение контекста занимает немало времени. Поэтому сравнение на одном ядре и многоя дернике некорректно

| Сообщение посчитали полезным:

spinz

Так я же не время измеряю, а число прерываний. Как точно измерить длительность кванта я не знаю. Только если сравнить расчётное время по тск.

> Поэтому сравнение на одном ядре и многоя дернике некорректно

Сказал ведь что наложение маски affinity не оказывает влияния на результат. Что есчо не ясно.

-----
vx

| Сообщение посчитали полезным:

difexacaw пишет:
Когда окно выходит на первый план в клиентской системе, все потоки в процессе, содержащем тот поток, который владеет окном первого плана,получают утроенные кванты
Был у меня довеча такой случай, кинул я собаке кусок колбасы смотрю на неё ест нормально, как отведу взгляд так слышу быстрое чавканье с утроенной силой, так я повторял 3 раза, ничего не понял, накатил стакан водяры и до меня дошло....... продолжение в следующей серии

-----
Чтобы правильно задать вопрос, нужно знать большую часть ответа. Р.Шекли.

| Сообщение посчитали полезным:

ClockMan

Про изменение квантования говорил VOLKOFF, читая вин интерналс. Я же доверяю исключительно прямым тестам.

-----
vx

| Сообщение посчитали полезным:

difexacaw пишет:
Так я же не время измеряю, а число прерываний.
Число прерываний с учетом планировщика. Пока контекст переключается при cli - это немного, но все равно влияет - есть временной лаг. Плюс не забывай, что IPI могут обрабатываться дольше настоящих интераптов

| Сообщение посчитали полезным:

spinz

Замер задуман так, что бы не время какое то измерять, а число возвратов по iret. А межпроцессорные прерывания тут вообще не причём. При любом iret происходит сброс rpl. Посмотри в табличку хотябы, как установка таймера влияет на замер.

-----
vx

| Сообщение посчитали полезным:

difexacaw
Смею предположить т.к окно главное то скорее всего активизируется GDI для прорисовки объектов, вот тут и получается такая разница?)))

-----
Чтобы правильно задать вопрос, нужно знать большую часть ответа. Р.Шекли.

| Сообщение посчитали полезным:

difexacaw пишет:
Замер задуман так, что бы не время какое то измерять, а число возвратов по iret. А межпроцессорные прерывания тут вообще не причём. При любом iret происходит сброс rpl.
Ты тупое? Межпроцессорные прерывания = немало тиков шины + софтовое переключение контекста.

| Сообщение посчитали полезным:

ClockMan

Так ведь если ресурс забирают, то потеря времени должна привести к понижению числа, а по факту наоборот происходит. Есть вероятность что при обработке прерывания часиков идёт серия софт прерываний. Но это лишь догадка.

Добавлено спустя 1 минуту
spinz

> Ты тупое? Межпроцессорные прерывания = немало тиков шины + софтовое переключение контекста.

Нет я не тупое", это походу ты тупишь. Каким боком тут IPI и процы, если я не измеряю время, а только число возвратов из ISR ?

-----
vx

| Сообщение посчитали полезным:

Ага. Вошел в ISR на одном ядре, а возврат из другого. Конечно же, время будет одинаковое))
Мне сразу вспомнился эмсирем в давней дискуссии про многоядерность

| Сообщение посчитали полезным:

spinz

Так ядро устроено. При прерывании контекст выгружается, затем при возврате загружается в процик. Когда время кванта истекает может быть переключение на иной процик, но это не изменяет механизм возврата - контекст загружается в другой процик и опять же происходит возврат по iret. Да и вообще какая разница, если нет эффекта. Я же измеряю, а не гадаю

-----
vx

| Сообщение посчитали полезным:

difexacaw пишет:
Да и вообще какая разница, если нет эффекта.
Эффект есть, но не при обсуждении этого треда, здесь конечно оверхед при переключении контекста не роляет.
Я больше про то, что клерк все-таки не всегда учитывает нюансы

| Сообщение посчитали полезным:

spinz

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

Для упрощения общения используем сокращения, interrupts per second(IPS) и quants per second(QPS).

-----
vx

| Сообщение посчитали полезным:

difexacaw пишет:
Смена аффинитета на один процик эффекта не оказывает.
Ну и глупо. Ты привычно юзаешь виндовые механизмы, т.к. больше ничего не умеешь. Напиши с нуля свой замерщик и тогда можно обсудить его эффективность

Добавлено спустя 1 минуту
С нтлдр был похожий спор когда то

| Сообщение посчитали полезным:

spinz

> Ты привычно юзаешь виндовые механизмы, т.к. больше ничего не умеешь.

Да, тема про нт. Заметь что замер не через системные механизмы, а прямой. Статистику из системы можно взять только в виде числа переключений контекста. IPS же ядро не считает(точнее считает для каждого проца в PCR, но не для потока). Есчо можно почитать дельту прерываний часиков, но тогда получится не снятие IPS, а замер времени про который ты говоришь. Либо число прерываний часиков, а толку от этого - никакого.

-----
vx

| Сообщение посчитали полезным:

Епт, ну напиши дровину именно для снятия hpet, тсо или 8254 при заблоченных других ядрах, тогда и поговорим за перфоманс. Щас ты обсуждаешь сферические интерапты в вакууме

| Сообщение посчитали полезным:

spinz

В эталонной системе высокоточные таймеры выключены. Именно поэтому я для теста и выбрал самый простой билд нт. На старших версиях используется куча хард таймеров и шедулер весьма сложен. Есчо ядро изменяет контекст, в замер вносится шум(как результат планирования).

-----
vx

| Сообщение посчитали полезным:

ну понятно, ты пошел по простому пути, т.к. на сложном пути есть вещи, которые ты не знаешь и не хочешь знать.
Для тебя все сводится просто к кодовой базе XP 32bit, а все остальное слишком сложно изучать

| Сообщение посчитали полезным: