Board.KolibriOS.org

Программа тестирования скорости выполнения заднного кода.
Тестирует как системный функции так и все остальное, наглядные результаты:
1. количество проходов. Для объективности код проганяется заданное количетсво раз, все результаты сохраняются и
2. выводятся данные тактов для каждого прохода
3. размер тестируемого кода. Определяется тоже автоматически
Все настройки в исходнике, который пока выкладывать небуду потому что мне интересны ваши идеи, что еще можно сделать.

В собарнном варианте тестируется функция 48 перерисовки фона.
У меня сразу возникла мысль. нужно везде в описаниях системных функций написать что либо все блокирующие либо какие-то такие другие сякие...
http://meos.ru/files/software/system/FuncTest.7z

1. Можно считать как такты, так и время.
2. Для коротких процедур можно учитывать переключение задач (если счетчик тиков не изменился, то переключения задач не было, а по частоте возникновения таких ситуаций расчитывать среднее время выполнения короткой процедуры). Но это достаточно сложный подход.

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

Счетчик тиков может изменится без переключения контекста на пару тиков благодаря суперскалярной архитектуре, поэтому чтобы проверить переключался ли контекст нужно задать число тиков которые бы говорило: тиков прошло больше чем указано, да было переключение, тиков прошло меньше - переключения небыло.
Поэтому для того чтобы посчитать среднее время переполнения процедуры нужно учесть
1. overhead пустой проверки, присутсвует только код сохранения параметров.
2. "чистый" (без вычетов) o. заданного кода
3. как реализовать проверку переключения контекста я непонимаю. Скорее всего это даже невозможно в силу того что процессор по разному рабоатет с одинм и тем же кодом, я считаю что проверять "уход" tsс неправильно, посколько он может сильно менятся и без переключения контекста. Может быть добавить в планировщик функцию которая бы инкрементировала бы счетчик переключений контекста? Т.е. Мы вызываем эту функцию и говорим ядру - нам нужно чтобы для этой программы работал счетчик переключений конеткста, ответ - 1 в случае согласия. И тогда мы можем проверять начальное положение счетчика переключений контекста, т.е. проверки будут на границах тестируемого кода.(конечное значение счетчика CSC (-con text swwitch counter) должно считатся после последнего rdtsc). В случае инкрементирования значения повторяем тест пока переключений небудет.
Пусть в данном вызове будет параметр куда (?) сохранять счетчик. Это обязательно должен быть регистр, чтобы планировщик не терял время на обращение к памяти тормазя при этом все процессы. Если будет функция с указанием регистра то мы можем вставить допустим тот же алгаритм с учетом того что регситр такой-то изменять категорически нельзя, т.е. при переключении быдует просто команда inc [r16/32]-(для контекста нашего патока) тем самым производительность системы практически не изменится.
Все сумбурно, но мысль вроде изложил.

Счетчик тиков может изменится без переключения контекста ...

Это как? Счетчик ([timer_ticks]) изменяется только в процедурах irq0 и change_task. irq0 всегда увеличивает его на 1, а change_task уменьшает его на 1 перед прямым вызовом irq0. Поэтому его значение никак не может изменится в обход переключения процессов. А multithreading MenuetOS не поддерживает. Счетчик тиков может не изменится при переключении процессов только при вызове функций задежки, ожидания событий, создания потоков/процессов, завершения процессов, и, возможно, обращения к файлам (код работы с файлами я еще не изучал, поэтому не знаю) - больше строка change_task нигде не встречается.

планировщик не терял время на обращение к памяти тормазя при этом все процессы

Планировщик неизбежно обращается к памяти, чтобы узнать какому процессу нужно передать управление.

Если будет функция с указанием регистра то мы можем вставить допустим тот же алгаритм с учетом того что регситр такой-то изменять категорически нельзя, ...

У планировщика свой набор регистров (по крайней мере пока он вызывается через шлюз вызова) и чтобы изменить регистр программы ему нужно лезть в память для изменения ее сегмента tss, в котором все эти регистры сохранены. Учитывая, что размер tss программы не степень двойки...
Проще всего сделать просто счетчик переключений, всегда увеличивающийся на 1 при вызове irq0. Осталось выбрать номер функции и подфункции для получения доступа к нему.
Кстати, ядро сообщает о количестве тиков, потраченных программой (эту информацию выводит, например, cpu) - это можно использовать.

Нашел вот это творение http://os-menuet.narod.ru/cor_task.htm
Но требуется подробное объяснение.

Это как?

Это параллельное выполнение инстркций.

Счетчик ([timer_ticks]) изменяется только в процедурах irq0 и change_task. irq0 всегда увеличивает его на 1, а change_task уменьшает его на 1 перед прямым вызовом irq0. Поэтому его значение никак не может изменится в обход переключения процессов.

Ты, насколько я понял, говоришь о программируемом таймере который выставлен на 100 Гц. А я говорю про счетчик tsc, счетчик количества выполненных инструкций процессором.

А multithreading MenuetOS не поддерживает.

Так получается что планировщик переключает только процессы? Сомнительно. Я почему-то думаю что потоки.

Если я напишу delay,0 произойдет ли task_switch?

Проще всего сделать просто счетчик переключений, всегда увеличивающийся на 1 при вызове irq0. Осталось выбрать номер функции и подфункции для получения доступа к нему

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

это можно использовать.

посматрю, подумаю

Так получается что планировщик переключает только процессы? Сомнительно. Я почему-то думаю что потоки

Я ошибся, имелся в виду hyperthreading. Параллельно могут выполняться без hyperthreading'а только несколько последовательных команд.

Только как его реализовать я пока незнаю. но буду думать\пробовать.

Это очень просто. Объясняю по шагам.
1. Выбираем место, где-нибудь перед или после irq0 (shed.inc).
2. Пишем: Мы объявили глобальную переменную в ядре.
3. В обработчике irq0 вставляем команду inc [context_switch] (например перед jmp irq0)
4. Теперь нужно добавить системную функцию. Пусть это будет функция 68, подфункция 0 (для примера).
5. Открываем файл syscall.inc и добавляем туда новый обработчик: dd sys_contextswitch после dd sys_window_move. (если используешь существующий номер, но в этой таблице ищешь адрес существующего обработчика и немного изменяешь его код)
6. В каком-нибудь файле пишем:

Я ошибся, имелся в виду hyperthreading. Параллельно могут выполняться без hyperthreading'а только несколько последовательных команд.

Тут еще нужно уточнить понятие "выполнятся".
Сколько конвееров в процессоре ~столько и интсрукций пораллельно могут обрабатываться. Одни могут даже раньше других, но применяются они в одной заданной пследовательности. Так вот неизвестно как работает счетчик в таких условиях, точнее известно что работает нестабильно, непонятно насколько точно считает. В последних процессорах конвееров больше 12. И как работает счетчик на них уже неочевидно, поэтому есть вероятность что они будет считать лишние такты. Вообще на последних процессорах им пользоваться уже бесполезно.

Есть синхронизирующие команды - cpuid например. Они гарантируют, что к моменту их выполнения все предыдующие команды будут считаны.
Забыл ответить на вопрос:

Если я напишу delay,0 произойдет ли task_switch?

Не произойдет. Нужно писать delay, 1 (так, например, мне пришлось писать в новом ICON для реализации мьютексов, чтобы поток передавал управление другим, вместо постоянной проверки занятости мьютекса в течении 0.01 секунды - ведь пока процессы не переключатся мьютекс уже не освободится).

А какие системные функции блокирующие неблокирующие? Или все блокирующие?

Дописываю прогу осталось только разобратся с двумя багами.

По идее, все системные функции не блокирующие. Но функции создания процесса, потока и перераспределения памяти блокируют переключение задач (командой cli) почти все время. Может еще есть функции надолго блокирующее переключение задач - я код всех функций менуета еще не изучил

Все функции в моём видеодрайвере обрамлены CLI/STI. Сейчас посмотрю, насколько это необходимо. Естественно, что без них работать будет быстрее, однако могут появиться глюки в отрисовке.

ПОЭТОМУ предлагаю вынести как отдельный проект строго стандартизированную документацию по ядру, функциям и прочему.
http://forum.meos.ru/index.php?t=15

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