Что дает real-time patch для Linux?

вопрос довольно интересный. риал там патчей нет. есть preemptible patch (от Роберта Лава) и минимум 2 low latency патча (Инго Молнар и Эндрю Мортон). это несколько не то, но направление тоже, задержка (latency) падает до 1-2 мс с 60-100 (то что ты назвал временным квантом... что тоже верно). насчет самих пачтей - патч для вытеснения процессов ядра (Robert Love) делает ядро вытесняемым за исключением 4х случаев (конкретно читай на кернелтрапе и лвн - нижние половины прерываний,сисколы,спинлоки и что-то еще, уже непомню), low latency patches - просто дополнительный набор непринудительных вызовов schedule функций (я не разбирал сырцы Молнара, но у Мортона сделано так, да и baldrick (Duncan Sands) вроде так же объяснял), в любом случае полного риал тайма тебе не будет но задержка отклика падает почти до минимума.

управление процессами? нет, ну впринципе ты сам можешь регулировать preempt_count для task struct (e.g. current из sched.h), но это не совсем механизм "управления жизнью".

вопрос и правда интересный, лично посоветовал бы посмотреть сырцы, там в сумме кил 200, не больше. если будут вопросы - пиши на asm(at)uinc.ru , c удовольствием поделюсь тем что откапал [не думаю что этим вопросом многие занимаются].

Существуют несколько real-time Линухов, но это - не патчи, а некие совершенно самостоятельные разработки. Тут я не спец, можешь поискать гуглем.

Сушествуют патчи к ядру (и не только), обеспечивающие те или иные фичи, характерные для real-time. Наиболее известные - патчи, обеспечивающие "вытесняемость" ядра - то есть "вытесняющая многозадачность" в режиме ядра, http://www.linuxdj.com/audio/lad/resourceslatency.php3

Наиболее известны среди них патчи от Robert Love и Andrew Morton. (Длинный и склочный флейм на ЛОР, почитай, интересно: http://www.linux.org.ru/view-message.jsp?msgid=157605)

Если не в курсе - традиционно процессы не рвутся планировщиком в состоянии ядра, то есть в состоянии ядра процесс монополизирует процессор и отдает управление только по своему желанию (точнее, процесс в режиме ядра можно прервать только в особых точках). Патч Andrew Morton (грубо говоря) ставит много таких точек, а патч от Robert Love (вернее, от Monta Vista) позволяет рвать процессы в состоянии ядра.

^^^ несколько коряво.

повторю еще раз, что б задавший вопрос не свернул влево - я бы не называл текущие разработки "real time". сам Роберт заявлял что это далеко не реальное время...

btw: это как раз то, что называется патчами. goto google на предмет low latency patch и preemptible patch

и опять-таки - ненадо мешать святое и праведное - патч от Мортона не обеспечивает вытесняющей модели многозадачности, а лишь искуственно прерывает ядро не особо оглядываясь на внешние факторы [это понижение задержки, low latency, а не preemptible]. просто идет вопрос "а не хочешь ли ты вытесниться?" и если need_resched заявляет - "да, я единица и очень этого хочу" - тогда идет смена tss [ну конечно не сразу...].

ps: к числу наиболее известных стоит добавить Молнара. он все-таки первым предложил концепцию low latency в linux и реализовал ее н практике.

ps2: патч уже больше от Лава чем от Monta Vista, хотя тут можно и поспорить...

2anonymous (*) (2003-02-26 01:57:55.976):
> ^^^ несколько коряво.
Это ты мне?

Но ты почти в точности повторил мои слова. Единственное верное замечание:
> к числу наиболее известных стоит добавить Молнара.
Согласен.

Все остальное, кроме ps2, по смыслу не отличается от того, что я писАл.

угу. тебе.

если на то пошло, то ты в своем _первом_ посте полностью повторил то, что было в _моем_ _первом_ посте [в этом же треде от 2003-02-25 22:32:53.823], согласен? ;-) зачем надо было вообще перефразировать то что находится на полэкрана выше, да еще и перефразировать с ошибками - не понимаю. ничего нового я там так и не нашел.

вообще, не считаю что это повод для обсуждений, повторил мою месагу, ладно я откорректировал... не суть важно . а на счет "того же самого":

ты пишешь: "Наиболее известны среди них [патчи, обеспечивающие "вытесняемость" ядра - то есть "вытесняющая многозадачность" в режиме ядра] - патчи от Robert Love и Andrew Morton" - это бред, патч от Мортона не обеспечивает вытесняющую многозадачность в привычном понимании. вытесняющая многозадачность подразумевает принудительное вытеснение ядра, а не добровольное. это уже пробел в основах... вот этого и касался мой второй пост.

еще замечания?

2anonymous (*) (2003-02-26 17:39:52.607):
> зачем надо было вообще перефразировать то что находится на полэкрана выше,
А ты на время посмотри.
Когда я начинал писАть, твоего поста еще не было, я его увидел только тогда,
когда свой отправил.

И, потом, IMHO я понятнее написАл ;)

> ...да еще и перефразировать с ошибками
Где?

> ...патч от Мортона не обеспечивает вытесняющую многозадачность в привычном
> понимании.
Это называется - к словам придираться.
Лова и Мортона обычно вместе упоминают, вот я и написАл про них. Непонимания
быть не могло (как я думал), взгляни на мое последнее предложение:
"Патч Andrew Morton (грубо говоря) ставит много таких точек, а
патч от Robert Love (вернее, от Monta Vista) позволяет рвать процессы в состоянии
ядра."
С чем ты не согласен, где ошибка?

Я тоже могу до тебя поддокопаться, типа
> ...то что ты назвал временным квантом...
Очевидно, что anonymous (*) (2003-02-25 16:30:03.016) имел в виду не это.

Ладно, обсуждать тут нечего. Я писАл одновременно с тобой и у тебя не
списывал.

А что такое latency?
Есть jiffies но в i386 он равен 100Гц (на Альфе кажется даже 1000), что есть 10 мс, но никак не 60-100
Или я чего-то не вкуриваю?

geekkoo

нет, не вкуриваешь, точнее вкуриваешь, но немного не то

jiffies - это только счетчик. не надо забывать что обработка прерывания тоже занимает время, но дело даже не в этом [а точнее совсем не в этом] - ядро само не отдавало прооцессор и долго держало его для своих процессов, потому и задержки были около сотни милисекунд. ведь не при каждом же появлении запроса от таймера переключение задач делать. в этом-то и весь ужас preemptible kernel - чем больше переключений задач и перезаписи tss, тем чаще очищается tlb кеш, а Максвел говорит, что частота удачных попаданий в tlb - около 90% ;-) [ну ясно что не всегда, но в любом случае принцип компактнности памяти/адресов еще никто не отменял]. так что реальное время никогда по общей производительности системы не переплюнет "время не_реальное"

цитата Лава: Robert: I'll start with a quick explanation of how the patch works. Right now, the kernel is not preemptible. This means that code running in the kernel runs until completion, which is the source of our latency. Although kernel code is well written and regulated, the net result is that we effectively have an unbounded limit on how long we spend in the kernel. Time spent in kernel mode can grow to many hundreds of milliseconds. With some tasks demanding sub-5ms latencies, this non-preemptibility is a problem.

теперь понятно о чем идет речь?

latency? вобщем-то это задержка, в любом словаре есть, но на практике - это время отклика системы

на всякий пожарный дам пару линков: http://kerneltrap.com/node.php?id=187 http://kerneltrap.com/node.php?id=464 http://linuxjournal.com/article.php?sid=5755 http://linuxjournal.com/article.php?sid=5600

wbr, Eugene

2Die-Hard: спорить и правда не о чем, но:

Лава и Мортона упоминают вместе лишь для того, что бы поставить одному из них вопрос:

JA: There is another patch available (maintained by Andrew Morton) with the same end goal. How is your patch different?

или же

JA: We spoke with Robert Love last October, learning about his preempt patch. How does your low-latency patch differ from his?

[http://www.kerneltrap.com/node.php?id=1] [http://www.kerneltrap.com/node.php?id=10]

wbr, Eugene

Из всего этого можно сделать вывод что latency это грубо говоря время переключения из kernel space в user-space - или я снова промазал?
Если так - то тогда этот preemptible kernel - пофиг. Задачи критичные к 5 мс задержке нужно в ядре реализовывать (или равномерно размазывать между ядрои и user-space-ом)

geekkoo

для меня такая формулировка вопроса слишком сложна.

вобщем идея в чем: latency - это просто время, за которое система сможет гарантированно [ну или более менее гарантированно] дать отклик запрос от девайса, юзера и тп. при использовании методики вытесняемого ядра в общем случае kernel space = user space если речь идет о политиках планирования (ну я утрирую, но идея такая). потому latency - это не не столько "время переключения из kernel space в user-space", сколько просто время переключения, так как ядро гиппотетически может быть вытеснено ядром (другим процессом ядра), или же планировщик может вытеснить пользовательский процесс таким же пользовательским но, к примеру, с большим приоритетом. вот среднее время переключения и примем за понятие latency. в идеальном варианте - это не среднее время, так как система реального времени должна при любых условиях реагировать с одинаковой задержкой которая -> 0, но увы - есть 4 вышеупомянутые случая (сисколы, шедулер, спинлоки и нижние половины прерываний [я так понимаю что последние не могут прерываться из-за какик-то race-причуд или же из-за того что они в забавной очереди находятся]), в связи с чем мы _уже_ не можем обеспечить одинаковую реакцию на запрос раз есть такие исключения, хотя, например, в ОС QNX прерываться в сисколах можно, но там система базируется на обработке сообщений, потому можно синхронизоровать время реакции на запрос за счет fake-овых посылок сообщений жертвуя при этом скоростью выполнения [c-ма будет обрабатывать ложные сообщения, что б дотянуться до интервала, за который она должна среагировать], но обеспечивая равенство временных интервалов.

потому.... если есть задача чувствительная к 5 ms задержкам - надо однозначно юзать low latency или лучше всего конечно preemptible ядро, хотя это уже неправильно - линукс на RTOS, так что это просто вытягивание за уши. но все-таки с 5 мс, ИМХО, справиться можно.

wbr, Eugene

Прошу прощения за навязчивость, но можно прокомментировать следующую фразу из Linux Device Drivers (http://www.xml.com/ldd/chapter/book/ch06.html)

The timer queue

The timer queue is different from the scheduler queue in that the queue (tq_timer) is directly available. Also, of course, tasks run from the timer queue are run in interrupt mode. Additionally, you're guaranteed that the queue will run at the next clock tick, thus eliminating latency caused by system load.

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

geekkoo

для начала уберем слово jiffies. о нем речь вообще не идет.

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

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

если есть необходимость прервать page_launder при попытке юзера подвигать мышкой - это будет сделано ядром [если нет preempt_disable()], не устраивает - ненадо использовать вытеснение в ядре.

это "очень плохо", если тебе нужна 5 ms реакция на событие, а ядро делает refill_inactive_list или IO_generic_file_read и ни за что не хочет отдавать процессор.

все зависит от того, чего хочет пользователь, от этого надо отталкиваться говоря о "хорошо" или "плохо", а не от "ИМХО".

ps: хочешь увидеть ключевую разницу в коде ядра для preemptible и non preemptible реализации:

/* это в ядре без preemptible patch */

movl EFLAGS(%esp),%eax # mix EFLAGS and CS movb CS(%esp),%al testl $(VM_MASK | 3),%eax # return to VM86 mode or non-supervisor? jne ret_from_sys_call

/* а это в ядре с preemptible patch */

movl EFLAGS(%esp),%eax # mix EFLAGS and CS movb CS(%esp),%al testl $(VM_MASK | 3),%eax # return to VM86 mode or non-supervisor? jne ret_from_sys_call

cmpl $0,preempt_count(%ebx) jnz restore_all cmpl $0,need_resched(%ebx) jz restore_all movl SYMBOL_NAME(irq_stat)+irq_stat_local_bh_count CPU_INDX,%ecx addl SYMBOL_NAME(irq_stat)+irq_stat_local_irq_count CPU_INDX,%ecx jnz restore_all incl preempt_count(%ebx) sti call SYMBOL_NAME(preempt_schedule)

[хотя заранее знаю в каком виде будут выглядеть эти 2 куска кода в этом... форуме]

wbr, Eugene

Из ассемблерного кода я только понял, что для non-preemptible ядра он короче :)

Лично мне 5 мс реакция на события не нужна - у меня реакция глаза 20 мс.
Это нужно девайсу - так для этого у него есть возможность прерываниями и таймером воспользоваться и чем бы ядро в этот момент не занималось эти события будут приняты и обработаны.

http://www.xml.com/ldd/chapter/book/ch02.html

Most devices are capable of interrupting the processor; interrupt handlers run asynchronously and can be invoked at the same time that your driver is trying to do something else. Several software (such as kernel timers ...) abstractions run asynchronously as well.

...

It is true that the Linux kernel is nonpreemptive; with the important exception of servicing interrupts, it will not take the processor away from kernel code that does not yield willingly.

geekkoo

ты ж сам в тексте используешь - "asynchronously" ;-)

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

2anonymous (*) (2003-02-27 12:11:58.735) aka Eugene:
> [хотя заранее знаю в каком виде будут выглядеть эти 2 куска кода в этом...
> форуме]
Там внизу кнопочка есть - надо выбрать "Preformatted text".

2geekkoo:
IMHO вытесняемое ядро Линуху совершенно не нужно.
Эта фича, характерная для реалтайма, при определенных обстоятельствах
порядком снижает общую производительность. Причины ее популярности IMHO:

1. Ее запихнули в Нтю, "шоб была" -- M$, как малое дитя, все в рот тянет --
далее M$ ее раскрутила как суперфичу (надо же было вложенные бабки
оправдывать!), и теперь считается, что современныя десктопная операционка
должна иметь вытесняемое ядро.

2. Вообще говоря, понятие latency наиболее обсуждаемо в контексте
веб-серверов. Низкая latency - один из ключевых показателей качества
веб-сервера. НО - там имеется в виду совсем ДРУГАЯ latency, определяемая
как временной лаг между началом запроса данных и моментом получения
последнего бита. У многих выстраиваются ассоциация:
Линух - веб-сервер - низкая latency - preemptable kernel - very good

Если не жалко времени, почитай ЛОРовский флейм по поводу Лововского патча.
Ссылку я уже давал, еще раз:
http://www.linux.org.ru/view-message.jsp?msgid=157605

2Die-Hard: сенькс за хинт на счет текста

>IMHO вытесняемое ядро Линуху совершенно не нужно. тут все зависит от постановки задачи.

ведь не платить же несколко тысяч у.е. за QNX или не покупать ту же НТ, только из-за того, что ПО требует тех же 5 ms, а патчить ядро не очень-то хочется. сейчас не так уж и много gnu/bsd RT систем.

anonymous (*) (2003-02-27 16:58:26.051):
>> IMHO вытесняемое ядро Линуху совершенно не нужно.
> тут все зависит от постановки задачи.
Конечно. Я имел в виду, что в обсуждаемом контексте обычно рассматривается
вполне определенная задача - десктопная система.

> ведь не платить же несколко тысяч у.е. ...
Ну, насколько мне известно, существуют по крайней мере 2 RT Линуха.
Наверное, в этом случае надо их использовать.

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

На мой взгляд сухой остаток будет выглядеть примерно так:
1. Для регистрации внешних событий preemptible патч не дает ничего, прерываний и таймеров хватает.
2. Для реакции на события кое-что preemptible patch все же дает (коль скоро все согласны, что в обработчике прерываний обратную связь организовывать не стоит). А именно - позволяет принудительно выгружать ядерные процессы, которые гоняют длинные циклы и при этом не беспокоятся о том, чтобы в циклах вызывать shedule.

OK?

geekkoo

верно

wbr, Eugene

А мне данный вопрос интересен в практическом смысле. Сейчас на моем ядре (2.4.20-ac2) при формировании большого loop файла на винте (dd if=/dev/zero of=/file count=2000000) у меня вся отальная работа практически замораживается. Имеет-ли мне смысл в связи с этим наложить обсуждаемые патчи?

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

на счет VM [virtual memory, подсистема управления памятью]: как вариант могу предложить O_DIRECT патч от Андреа Арканджели (и вроде бы у Моргана был свой патч в этом направлении). возможно, прямой ввод-вывод спасет отца русской демократии, точнее уменьшит скорость создания файла. =)

скажу только, что в случае использования не 2.4.20-ac2, а, например, 2.4.19-ac# - ситуация могла бы быть и хуже - [могу ошибаться, но вроде бы так] Алан Кокс в этой версии (ac патч для 2.4.20) отказался от реверсивного маппинга Рика ван Риля, который создал бы дополнительную нагрузку на память [вот потому начиная с 2.4.20 я и не ставлю патчей Кокса].

еще можно покопать в направлении dropbehind, хотя это не совсем потоковые данные. может ядро при чтении из /dev/zero долго держит страницы в кеше, а если памяти мало - может уходить в своп параллельно с записью на винт самих данных, отсюда и тормоза...

ps: хотя все это догадки.

wbr, Eugene

UncleAndy: чаще всего это говорит о том, что ядро много времени проводит перелопачивая данные с винта процессором, отсюда вывод --- врубить DMA в ядре для своего чипсета, потом hdparm'ом врубить винту что-нибудь такое: /sbin/hdparm -c1 -u1 -d1 -m16 /dev/hda

за подробностями в man hdparm ;)

UncleAndy (*) (2003-02-28 10:51:26.862):
Попробуй параметрами hdparm поиграть, 99%, поможет. Только осторожнее,
повиснуть может.

2anonymous (*) (2003-02-28 12:11:16.906) aka Eugene
А, вообще, лововский патч может помочь:
$ ls -l:

... 324710400 Feb 28 12:54 qqq
$ time dd if=qqq of=qq:
real 0m39.979s
user 0m1.250s
sys 0m6.380s
Т.е., процесс в ядре болтается больше, чем юзерспейсе.

2anonymous (*) (2003-02-28 14:45:12.437):
Блин, опять я стормозил!

Не видел твоего совета, когда начинал писАть. Пока подбирал файл, пока гонял
dd ...

по поводу dd, вполне средний сундук по нынешним временам на kt266,
винт макстор 7200рпм, вываливает 30-35MB/s если только читать или писать,
если читать с винта и писать на нео-же то по 13-16 в зависимости от
места диска:

ls -l warcraftIII-margo.iso; time dd if=warcraftIII-margo.iso of=kkk
-rw-r--r--    1 ds       ds       650119168 Jan 30 22:08 warcraftIII-margo.iso
1269764+0 records in
1269764+0 records out
650119168 bytes transferred in 47.856450 seconds (13584776 bytes/sec)

real    0m47.895s
user    0m0.770s
sys     0m4.410s

time dd if=warcraftIII-margo.iso of=/dev/null
1269764+0 records in
1269764+0 records out
650119168 bytes transferred in 19.252048 seconds (33768832 bytes/sec)

real    0m19.283s
user    0m0.510s
sys     0m1.980s

athlonxp 1600+, a7v266 (kt266), 256MB ram, kernel 2.4.20

hdparm /dev/hda

/dev/hda:
 multcount    = 16 (on)
 I/O support  =  1 (32-bit)
 unmaskirq    =  1 (on)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 nowerr       =  0 (off)
 readonly     =  0 (off)
 readahead    =  8 (on)
 geometry     = 3736/255/63, sectors = 60030432, start = 0
 busstate     =  1 (on)

hdparm -i /dev/hda

/dev/hda:

 Model=Maxtor 5T030H3, FwRev=TAH71DP0, SerialNo=T3RJTGVC
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=60030432
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4
 DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2
 AdvancedPM=yes: disabled (255) WriteCache=enabled
 Drive Supports : ATA/ATAPI-6 T13 1410D revision 0 : ATA-1 ATA-2 ATA-3 ATA-4 ATA-5 ATA-6


HTH /тот анонимус который hdparm советовал.

да. забыл сказать, загрузка процессора при всех этих делах процентов 15

Так дело-то в том, что при всем при этом загрузка проца никак не привышает 10%. А тормоза как будто он на 90-100% загружен. Просто загадка какая-то. Проц не загружен, а все тормозит. :(

Кстати, та-же ситуация при формировании имиджа CD через mkisofs.

UDMA на винте конечно включен.