Перехват переключения контекста

http://tldp.org/HOWTO/Module-HOWTO/

Ничего, что переключение контекста может происходить тысячи раз в секунду?

Можно ткнуть носом в то место, которое мне нужно? Перехватить системный вызов я бы смог - но в том куске ядра я их не нашел.

Ничего.

Система встанет колом после такого «внедрения». Какова цель записи pid'а в файл?

это невозможно..

погромисты такие погромисты, в ядре нельзя просто взять и захерачить что в голову взбрело. это не «еще одна программа»

По легенде - ответ программисту на ответ - почему в этот раз его программа выполняется дольше, чем в другой. А по факту - навязанная тема курсовой работы.

Та ссылка — мой хук на фразу «Никогда раньше не сталкивался с программированием модулей».

Думаю, в ftrace уже есть что-то такое (но модуль писать не нужно).

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

Если есть возможность заюзать SystemTap, то смотри сюда: http://sourceware.org/systemtap/examples/keyword-index.html#SCHEDULER

почему в этот раз его программа выполняется дольше, чем в другой

SystemTap, kprobes, ...

А по факту - навязанная тема курсовой работы

Пиз.. отечественному образованию и машиностроению.

ftrace, как я понял, отслеживает только системные вызовы.

ftrace, как я понял, отслеживает только системные вызовы.

Ты понял неправильно (или путаешь линуксовый ftrace с ptrace, systrace или еще каким-то *trace). ftrace отслеживает почти всё, что угодно. Планировщик оно отслеживает точно.

По задумке не один, но некий фиксированный список процессов. SystemTap заюзать нельзя, нужно написать свой модуль. Но именно он ближе всего, что я видел, к тому, что мне надо. По ссылке - process/schedtimes.stp - Track Time Processes Spend in Various States Using Tracepoints. Но я сильно боюсь завязнуть в разбирании кода такого большого проекта.

А если сделать это в виде планировщика?
Ну и в файл реально писать как можно реже, это понятно.

Можно чуть-чуть разжевать на тему планировщика? По задумке это будет писаться куда-нибудь в /proc/ (оно же, вроде как, все в оперативной памяти)

Дык если в /proc, то оно вообще не так реализуется, как с обычными файлами… В плане того, например, что информация будет реально записываться в файл только перед открытием.

Я всех премудростей не знаю, поправьте, если не так.

Проблема - не в том как и куда писать. Проблема в том, как технически перехватить переключение контекста (к примеру, функции switch_to() из kernel/sched.c).

// черт! а я тока что перечитал исходный пост, увидел «текст задания», подумал, что я его сраза не заметил и удалил свое сообщение %)

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

т.е., наверняка планиркется заносить номера процессов в какой-то /proc-файл, и мониторить перекчючения контекста только тех процессов?

Да, именно так.

Херню посоветовал, в самом-то деле. Не разбираешься - не лезь.

Если /proc то оно ведь никуда не пишется (в смысле на носитель). Просто э
экспортируются пару вызовов вроде open/read/write/close и пользователь работает как с обычным файлом. А он себе в буфере пиды будет держать и по read'у отдавать пользователю.

Можно чуть-чуть разжевать на тему планировщика?

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

Тупо вставь printk в функцию schedule. Лог файл - файл сислога...

Рекомендую купить/скачать книгу Роберта Лава. Там такие дела достаточно детально рассмотрены.

Да - и преподаватель - дебил

Мне казалось, или планировщик вшит в ядро? Как мне его без перекомпилирования ядра изменить, в виде модуля?

Проблема - не в том как и куда писать. Проблема в том, как технически перехватить переключение контекста (к примеру, функции switch_to() из kernel/sched.c).

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

Мне казалось, или планировщик вшит в ядро? Как мне его без перекомпилирования ядра изменить, в виде модуля?

не получится, перекомпилировать придется. А в чем, собственно, проблема перекомпилировать?

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

Проблема в ТЗ.

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

Проблема в ТЗ.

Проблема в аналитиках тогда уже

А насколько реально подменить вызов функции ядра вызовом функции модуля в рантайме?

А насколько реально подменить вызов функции ядра вызовом функции модуля в рантайме?

вполне реально. Только, вроде как заранее неизвестно, по какому адресу будет модуль загружен, придется самому определять. Или выделить кусок памяти, скопировать туда свою функцию, и потом затереть адресом этого куска адрес функции switch_to вызов

call _switch_to() => call 0xABCDE

как-то так

Спасибо, большое! Вполне реальный вариант, но он выглядит все-таки «грязным». Хотя, конечно, он будет работать и, если ничего лучше не придумаю - придется делать его. В связи с этим, хотелось бы услышать другие варианты. К примеру, что-то похожее есть в SystemTap, но у меня нет идей, где и как это искать.

может препод не так выразил мысль, а хотел мониторить task->state?

может препод не так выразил мысль, а хотел мониторить task->state?

Похоже, преподаватель хотел, чтобы они написали что=-то сами. То, что задача решена давно и несколькмим способами, его не волновало.

А насколько реально подменить вызов функции ядра вызовом функции модуля в рантайме?

Это kprobes.

Ага, ну я так примерно себе и представлял.

На всякий случай спрошу: а как это мониторить? Хоть я и уверен в формулировке.

скорее всего предложу неправильный способ, но я бы попробовал

cur_state = task->state;
wait_event_interruptible(wq, task->state != state)

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

Если я не ошибаюсь то планировщик может быть оформлен в виде модуля. Хотя я не уверен.

Посмотри на kprobes, он умеет подменять функции

А если планировщик не можно сделать модулем то что если тогда «повесится» на прерывание таймера и по этому тику смотреть текущий процесс и соответственно решать было ли переключение?

а процессоров может быть несколько, соотв. и текущих процессов тоже :)

Хм, даже в гугле на первой же странице ЛОР 2004-го: KProbes позволяет добавлять (и убирать) отладочные printk-вызовы в ядро без перезагрузки. Что-то оно очень тихо и немноголюдно обсудилось.

что если тогда «повесится» на прерывание таймера и по этому тику смотреть текущий процесс и соответственно решать было ли переключение?

:) то есть принудительно заставит систему почаще переключать контексты ?

хотя мысль про таймеры здравая - при переключении контекста от/к задаче ядро обновляет статистику задачи и её таймеры, причём это независит от выбранного планировщика; то есть где-то туда можно прицепиться и собрать pid`ы в кольцевой буфер.