LINUX.ORG.RU

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


0

1

Никто не знает сколько надо времени ядру Linux чтобы отреагировать на прерывание, при условии что линия прерывания совместно не используется, архитектура arm, частота проца 200 МГц. Нсть способ померить сие характеристику?

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

sn1ln ()

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

dimon555 ★★★★★ ()
Ответ на: комментарий от dimon555

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

mskmsk1985 ()
Ответ на: комментарий от mskmsk1985

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

4.2

Led ★★★☆☆ ()
Ответ на: комментарий от sn1ln

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

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

Skolotovich ★★★ ()

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

Dead ★★★★ ()
Ответ на: комментарий от Eddy_Em

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

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

Led ★★★☆☆ ()

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

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

anonymous ()

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

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

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


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

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


гугли «linux measuring interrupt latency»

anonymous ()
Ответ на: комментарий от mskmsk1985

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

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

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

idle ★★★★★ ()
Ответ на: комментарий от idle

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

mskmsk1985 ()
Ответ на: комментарий от mskmsk1985

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

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от mskmsk1985

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

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от Eddy_Em

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

mskmsk1985 ()
Ответ на: комментарий от mskmsk1985

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

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


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

по теме: hrtimers

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


улыбнуло

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


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

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

idle ★★★★★ ()
Ответ на: комментарий от Eddy_Em

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

ну нет же

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

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


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



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

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

idle ★★★★★ ()
Ответ на: комментарий от idle

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

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

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от idle

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

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

anonymous ()
Ответ на: комментарий от idle

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

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

mskmsk1985 ()
Ответ на: комментарий от anonymous

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

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

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

idle ★★★★★ ()
Ответ на: комментарий от Eddy_Em

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

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

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

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


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

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

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



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

idle ★★★★★ ()
Ответ на: комментарий от mskmsk1985

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

я ответил: hrtimers

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


это timer_list

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


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

idle ★★★★★ ()
Ответ на: комментарий от idle

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

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

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от mskmsk1985

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

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

idle ★★★★★ ()
Ответ на: комментарий от idle

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

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


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

anonymous ()
Ответ на: комментарий от Eddy_Em

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

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

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

idle ★★★★★ ()
Ответ на: комментарий от idle

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

mskmsk1985 ()
Ответ на: комментарий от idle

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

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

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от anonymous

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

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


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

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

idle ★★★★★ ()
Ответ на: комментарий от mskmsk1985

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

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от mskmsk1985

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от anonymous

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

mskmsk1985 ()
Ответ на: комментарий от Eddy_Em

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от Eddy_Em

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

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

anonymous ()

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

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

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

MKuznetsov ★★★★★ ()
Ответ на: комментарий от MKuznetsov

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

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

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

тут еще важно, о каком обработчике идет речь. самое интересное, это вызов 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);
 	/*
idle ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.