Сколько надо времени?

do_irq() на вход и выход поставить printk :)

взводишь таймер на известное время, сохраняешь куда-нибудь время и ждёшь. по приходу в обработчик измеряешь время, находишь разность, получаешь что-то похожее на interrupt response time. повторяешь процедуру пару миллионов раз, считаешь наихудшее и среднее время... профит.

Таймера в обычном ядре не очень точны (порядка милисекудны) меня интересуют временные интервалы от 2ю5 до 40 микросекунд

>Таймера в обычном ядре не очень точны (порядка милисекудны)

4.2

do_irq() на вход и выход поставить printk :)

и потом отнимаешь время отработки printk, уже наступали (:

do_irq() на вход и выход дернуть какой-нибудь gpio. Время замерять осцилом.

Но есть же погрешность порядка наносекунд...

>Но есть же погрешность порядка наносекунд...

Но есть же «небольшая» разница между «миллисекундами» и «наносекундами»:)

Есть :)

> Нсть способ померить сие характеристику?

Осциллограф + генератор.

>Никто не знает сколько надо времени ядру Linux чтобы отреагировать на прерывание

Никто не знает

архитектура arm, частота проца 200 МГц.

ниочем не говорит

Нсть способ померить сие характеристику?

гугли «linux measuring interrupt latency»

> Таймера в обычном ядре не очень точны (порядка милисекудны)

ужос. это не так, таймеры в полном порядке.

но тебе это не нужно, все уже сделано для тебя.
см irqsoff в Documentation/trace/ftrace.txt

>ужос. это не так, таймеры в полном порядке И как по вашему поставить таймер на 250 микросекунд (ВНИМАНИЕ: ИМЕННО ТАЙМЕР А НЕ ЗАДЕРЖКУ)? Пример в студию!

А никак, если у вас не система реального времени. Пара-тройка микросекунд (а при значительной нагрузке - и больше) спокойно может «потеряться», пока ядро будет делить процессорное время.

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

Мне вообще надо гарантировать отклик системы на внешнее событие, причем гарантировать время отклика порядка 2 - 30 микросекунд и чем меньше тем лучше (это не допустимый разброс а интервал из которого нужно выбрать конкретное время которое я могу гарантировать).

что ж ты за человек такой... последний раз я тебе отвечаю.

И как по вашему поставить таймер на 250 микросекунд

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

по теме: hrtimers

(ВНИМАНИЕ: ИМЕННО ТАЙМЕР А НЕ ЗАДЕРЖКУ)

улыбнуло

Пример в студию!

я так понимаю, это у тебя такой способ сказать спасибо
за ответ на предыдущий вопрос.

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

> А никак, если у вас не система реального времени.

ну нет же

Пара-тройка микросекунд (а при значительной нагрузке -

и больше)спокойно может «потеряться», пока ядро будет

делить процессорное время.

ну о чем ты. речь же про timers, те irq.

другое дело interrupt latency, но это другое дело.

Т.е. сигналы по alarm гарантированно будут генерироваться ровно по истечению таймера? А если ядро будет «слишком сильно занято», чтобы «вспомнить» про этот таймер?

Если нужна повышенная стабильность временных промежутков, то, ИМХО, нужно ставить ядро реального времени и использовать специальное железо с проститwatchdog'ами и аппаратными таймерами.

>но тебе это не нужно, все уже сделано для тебя.
см в Documentation/trace/ftrace.txt

Не понял - какое отношение это имеет к измерению латентности прерываний ? По моему вы путаете теплое с мягким.

Вы мне уверяете что таймеры в полном порядке, так вот тогда вопрос а о каких таймерах речь идет? Я про те что программно в ядре реализованы и у них точность порядка миллисекунд (по крайней мере в ванильном). Свободных аппаратных таймеров у меня в распоряжении нету. Остальные методы пошел осваисать.

ЗЫ: Тратьте свое время куда Вам угодно, хотя лучше подучитесь разговаривать и освойте предмет.

> По моему вы путаете теплое с мягким.

a по-моему, вам нужно прочитать trace.txt ;)

но сначала внимательно прочитать 1 строчку,
которые я написал: «см irqsoff в ...».

Тут вопрос как раз о рассмотрении interrupt latency, если что.

> Т.е. сигналы по alarm гарантированно

ну при чем здесь alarm/сигналы.

еще раз, речь идет о таймерах в ядре. конечно, alarm/etc
использует те же таймеры, но это же совсем другой уровень.

нужно ставить ядро реального времени

ну, смотря для чего

использовать специальное железо с проститwatchdog'ами и

аппаратными таймерами.

они и так аппаратные. тут какая-то путаница уже.

> так вот тогда вопрос а о каких таймерах речь идет?

я ответил: hrtimers

в ядре реализованы и у них точность порядка миллисекунд

это timer_list

хотя лучше подучитесь разговаривать и освойте предмет.

спасибо за советы.

они и так аппаратные.

Только «командуют» они ядром, и ядру решать, когда послать вашему приложению нужный сигнал при срабатывании таймера.

> Тут вопрос как раз о рассмотрении interrupt latency, если что.

тут как раз речь шла про «делить процессорное время»,
если ты не заметил.

>> По моему вы путаете теплое с мягким.

a по-моему, вам нужно прочитать trace.txt ;)

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

> и ядру решать, когда послать вашему приложению

эта ;) ну в 3-ий раз уже, какое приложение? речь
шла о срабатывании таймера в _ядре_.

если мы говорим про user-space, то это совсем-совсем
другая тема. и да, rt может сильно помочь.

Ну-нуб продолжай вырывать фразы из контекста... Пошел за поп-корном.

Ну, я изначально считал, что речь идет про user space.

Если про ядро - то здесь и говорить не о чем.

> Да хоть зачитайся - измерить время от запроса аппаратного

прерывания до входа в обработчик это не поможет.

а! это правда. я не понял, что тебе нужно.

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

Во-во именно это мне и нужно померять.

Наверное, придется писать «самопальный» модуль ядра и использовать-таки rt.

>Во-во именно это мне и нужно померять.

Даже без измерений - в linux все хреново с этим и rt-патч который якобы делает из linux hard rt систему - это сказки и лучше не будет никогда, потому что спроектирована она изначально не для таких задач. На сегодня linux как ОС безнадежно устарел, вернее даже на момент появления он уже был г-ом мамонта :)

Ну не покупать же для простеньких вещей QNX!

Интересно бы узнать почему? (для не сведующих типа меня)

>Ну не покупать же для простеньких вещей QNX!

Для каждой задачи есть решение - для реалтайма linux не подходит, но это же не значит что нужен qnx, намного чаще сам реалтайм не нужен :)

Ну, иногда realtime нужен, например, если вы управляете шестиметровым телескопом :)

>Ну, иногда realtime нужен

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

Нсть способ померить сие характеристику?

исключительно программно - нет.

аппаратно - как можно раньше в обработчике поставить вывод в порт (outb или как там будет на ARM`е). Затем либо осцилогрофом замерить время между двумя сигналами. Либо цеплять линию IRQ на (ре)старт внешнего быстрого счётчика/таймера а упомянутый порт на его-же стоп/латч и считывать показания хоть в вашем же обработчике.

исключительно программно - нет.

мне все-таки стало интересно, можно ли это примерно измерить.

как можно раньше в обработчике

тут еще важно, о каком обработчике идет речь. самое интересное, это вызов interrupt gate (не знаю, как правильно сказать), и это скорее вопрос про hardware, в котором я абсолютно не разбираюсь. дальше-то тривиально мерить.

вот, накропал быдлопачч по-быстрому. забавно.

интересно, можно ли лучше. под kvm $ perl -le 'print syscall 157,666' докладывает ~ 5600 ticks. на реальной машине не мерил.

по-хорошему надо было бы reschedule_interrupt: менять, но это лениво, и там всего несколько insns.

--- 37/kernel/sys.c~estimate_ipi_lat	2010-09-14 17:48:41.000000000 +0200
+++ 37/kernel/sys.c	2011-02-17 16:43:14.000000000 +0100
@@ -1579,6 +1579,33 @@ SYSCALL_DEFINE1(umask, int, mask)
 	return mask;
 }
 
+DEFINE_PER_CPU(bool, please_set_ipi_tsc);
+DEFINE_PER_CPU(unsigned long long, ipi_tsc);
+
+long estimate_ipi_lat(void)
+{
+	unsigned long long now, ipi;
+
+	preempt_disable();
+	WARN_ON(this_cpu_read(please_set_ipi_tsc));
+
+	native_irq_disable();
+	smp_send_reschedule(smp_processor_id());
+
+	this_cpu_write(please_set_ipi_tsc, true);
+
+	now = __native_read_tsc();
+	native_irq_enable();
+
+	cpu_relax();
+	WARN_ON(this_cpu_read(please_set_ipi_tsc));
+	ipi = this_cpu_read(ipi_tsc);
+
+	preempt_enable();
+
+	return ipi - now;
+}
+
 SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, arg3,
 		unsigned long, arg4, unsigned long, arg5)
 {
@@ -1592,6 +1619,9 @@ SYSCALL_DEFINE5(prctl, int, option, unsi
 
 	error = 0;
 	switch (option) {
+		case 666:
+			return estimate_ipi_lat();
+
 		case PR_SET_PDEATHSIG:
 			if (!valid_signal(arg2)) {
 				error = -EINVAL;
--- 37/arch/x86/kernel/smp.c~estimate_ipi_lat	2010-11-02 19:48:04.000000000 +0100
+++ 37/arch/x86/kernel/smp.c	2011-02-17 16:43:18.000000000 +0100
@@ -193,6 +193,9 @@ static void native_stop_other_cpus(int w
 	local_irq_restore(flags);
 }
 
+DECLARE_PER_CPU(bool, please_set_ipi_tsc);
+DECLARE_PER_CPU(unsigned long long, ipi_tsc);
+
 /*
  * Reschedule call back. Nothing to do,
  * all the work is done automatically when
@@ -200,6 +203,20 @@ static void native_stop_other_cpus(int w
  */
 void smp_reschedule_interrupt(struct pt_regs *regs)
 {
+	unsigned long long now;
+
+	now = __native_read_tsc();
+	/*
+	 * we didn't do irq_enter(), suppress the possible
+	 * problems with _check_resched() from this_cpu_*()
+	 */
+	preempt_disable();
+	if (this_cpu_read(please_set_ipi_tsc)) {
+		this_cpu_write(please_set_ipi_tsc, 0);
+		this_cpu_write(ipi_tsc, now);
+	}
+	preempt_enable_no_resched();
+
 	ack_APIC_irq();
 	inc_irq_stat(irq_resched_count);
 	/*