Linux real time patch

Realtime kernel patchset

This article describes the Linux kernel realtime patch set, and some utilities useful for trouble shooting scheduling latencies.

Contents

What is realtime?

Realtime applications have operational deadlines between some triggering event and the application’s response to that event. To meet these operational deadlines, programmers use realtime operating systems (RTOS) on which the maximum response time can be calculated or measured reliably for the given application and environment. A typical RTOS uses priorities. The highest priority task wanting the CPU always gets the CPU within a fixed amount of time after the event waking the task has taken place. On such an RTOS the latency of a task only depends on the tasks running at equal or higher priorities; tasks running at lower priorities may be ignored. On a non-realtime OS (most GNU/Linux distributions running their default kernels), since latencies depend on each process running on the system, it is obviously much harder to ensure deadlines will be met every time, and this difficulty scales nonlinearly with system complexity. Determinism in scheduling becomes yet more difficult to achieve because preemption can be switched off for an arbitrary amount of time. A high priority task wanting to run can thus be delayed indefinitely by lower priority tasks with preemption disabled.

How does the realtime patch work

The RT-Preempt patch converts Linux into a fully preemptible kernel. This is done through:

• Making in-kernel locking-primitives (using spinlocks) preemptible by reimplementation with rtmutexes.
• Critical sections protected by i.e. spinlock_t and rwlock_t are now preemptible. The creation of non-preemptible sections (in kernel) is still possible with raw_spinlock_t (same APIs like spinlock_t).
• Implementing priority inheritance for in-kernel spinlocks and semaphores.
• Converting interrupt handlers into preemptible kernel threads: The RT-Preempt patch treats soft interrupt handlers in kernel thread context, which is represented by a task_struct like a common user space process. However it is also possible to register an IRQ in kernel context.
• Converting the old Linux timer API into separate infrastructures for high resolution kernel timers plus one for timeouts, leading to user space POSIX timers with high resolution.

Installation

There are multiple -rt patched kernels available from the AUR. The main two are linux-rt AUR and linux-rt-lts AUR , which both have a configuration based on the main linux kernel package. linux-rt follows the development branch of the -rt patch, while linux-rt-lts tracks a stable branch of the rt patchset.

And then there also is linux-rt-bfq-dev AUR , which is based on the development version of the -rt patch and includes the BFQ scheduler, and a 2nd reference.

Scheduling latency

In the context of the scheduler, latency is the time that passes from the occurrence of an event until the handling of said event. Often the delay from the firing of an interrupt until the interrupt handler starts running, but could also be from the expiration of a timer, etc.

There can be many varied causes for high scheduling latencies. Some worth mentioning (in no particular order) are: a misconfigured system, bad hardware, badly programmed kernel modules, CPU power management, faulty hardware timers, SMIs and SMT.

When trying to determine a system’s maximum scheduling latency, the system needs to be put under load. A busy system will tend to experience greater latencies than an idle one. To sufficiently characterize latencies of interest, it would be prudent to run tests for a long time and under a variety of nominal and worst-case load conditions. Further, since many subsystems such as disks, network devices, USB and graphics may be used sparsely after a system is brought online, care should be taken to characterize latency with these subsystems active as well.

Latency testing utilities

Understanding latency is non-intuitive. In measuring and interpreting latency, errors are common and very likely to happen even with experienced computer scientists. Popular tools are often incorrect. This talk explains some common pitfalls. There are several tools available to check kernel scheduling latencies, and to track down the causes of latency spikes. One set of tools comes in a package called rt-tests .

cyclictest

One of the programs in rt-tests is called cyclictest, which can be used to verify the maximum scheduling latency, and for tracking down the causes of latency spikes. cyclictest works by measuring the time between the expiration of a timer a thread sets and when the thread starts running again.

Here is the result of a typical test run:

It shows a four CPU core system running one thread (SCHED_FIFO) per core at priority 98, with memory locked, the system is also under a high load due to running hackbench in a separate terminal. What is most interesting is the max schedling latency detected, in this case 32 usecs on core 3.

hackbench

An idle kernel will tend to show much lower scheduling latencies, it is essential to put some load on it to get a realistic result. This can be done with another utility in the rt-tests package called hackbench. It works by creating multiple pairs of threads or processes, that pass data between themselves either over sockets or pipes. To make it run longer add the -l parameter: hackbench -l 1000000 .

hwlatdetect

hwlatdetect can be used to detect SMIs taking an inordinate time, thus introducing latency by blocking normal kernel execution. It consists of a kernel module (present in both linux-rt and linux-rt-lts), and a python script to launch the process and report the results back to the user. To check if the system uses NMIs run the following command:

The hwlatdetect kernel module works by turning everything running on the CPUs off through the stop_machine() call. It then polls the TSC (Time Stamp Counter) looking for gaps in the generated data stream. Any gaps indicates that it was interrupted by a NMI, as they are the only possible mechanism (apart from a broken TSC implementation). To run the program for 120 secs, with a detection threshold of 15 usecs, execute the following:

The result shows 16 NMIs detected that exceeded the 15 usecs threshold specified, the maximum latency detected was 21 usecs.

Источник

Realtime Linux

Setting up and operating the RT kernel

In order to fulfill the requirements of a real-time system, a system must react to an external event like an interrupt within a defined time frame. Therefore several mechanisms, configurations and implementation rules have to be considered. Giving the Linux kernel possible real-time properties is not difficult:

• download the kernel
• download the PREEMPT_RT patch
• patch the kernel
• build the kernel
• restart your system
• choose the RT kernel

It is also easy to check whether the response behavior of the newly created kernel has actually improved:

• start cyclictest and wait for a few hours
• analyze and judge the result

What can be done if latencies are found, i. e. if the kernel starts the user program too late every now and then? There are different measurement methods for this, but this is not quite as easy as making the RT kernel.

For this reason, the individual measurement methods

• breaktrace with subsequent trace analysis
• continuous latency recording with peak detection

are described and explained with examples. In addition, there are frequently occurring latency sources such as

• frequency modulation and
• sleeping phases

which must be omitted.

Recapitulation: How do I create a realtime capable Linux kernel — e. g. on an Intel PC with a standard distribution?

First select the appropriate RT kernel, whose version is as close as possible to the kernel version of the respective distribution.
How to check kernel version on Linux: uname command: $ uname -r or as alternative the cat command $ cat /proc/version

For example, you can obtain the following information: linux-image-4.9.0-4-amd 4.9.51-1 This means you have kernel version 4, patch 9 and sublevel 51. On the download page of the Linux RT project you will find out that the RT patch patch-4.9.47-rt37.patch.xz is available there. This is the kernel that is closest to the current non-RT version. With the following commands the appropriate source code is downloaded, the patch is downloaded, the archive is unpacked and the patch applied:

To ensure that the RT kernel supports the current distribution as well as possible, the first step is to take over its kernel configuration, which is located in the /boot directory of Debian, as with many other distributions, and which matches the kernel version number. In this case, it is the file /boot/config-4–9.0–4-amd64 , which is now copied to the root directory of the kernel source code under the name .config :

cp /boot/config-4.9.0-4-amd64 .config

In the last step, before the kernel can be compiled, the new kernel has to be configured so that the functionality imported with the RT patch is also used. The command make menuconfig is called and we select Processor type and features -> Preemption Model -> Fully Preemptible Kernel (RT).

The kernel is then compiled, installed, and the system must be rebooted.

During the restart we select the RT kernel in the boot menu.

Now we have to verify the system’s response behavior.
As a first important step after rebooting, you should make sure that the new kernel is properly configured — at least formally. This is indicated by whether the flags PREEMPT and RT are included in the output of the program uname .

which is obviously the case here. A much better proof, however, is of course to create asynchronous events and check how long it takes the system to allow a user-space-process with real-time priority to react to them. The expected time span can be calculated with the rule of thumb

maximum_latency = clock_interval * 10⁵

This means that, for example, in a system with a clock frequency of 1 GHz and thus a clock interval of 1 ns, a maximum latency of less than 100 µs can be expected. The test program cyclictest, which is included in the RT-Test Suite rt-tests has proven itself for measuring the maximum reaction time of a userspace process and can be obtained from the following repository:

The program cyclictest also contains a histogram function with which so-called latency plots in the standard form can be produced. In this standard form, latency classes are plotted on the x-axis in µs with a granularity of one microsecond, and on the y-axis the frequencies of measurements per class are displayed in logarithmic representation. This is a histogram with the special feature that the logarithmic y-axis shows both very low and very high frequencies. A shell script can be used to execute cyclictest and generate a standard latency plot from the measured values:

It requires the prior installation of the gnuplot program which is included in most Linux distributions. And a program is required to display the plot.png latency plot generated by the script.

If the script is accepted unchanged, it has a runtime above 5 hours, generating data of 100 million cycles. For a meaningful result, suitable stress scenarios must be set up during the measurement. A typical result is shown in Figure 1 above. The scaling of the x-axis is deliberately very high to compare the result with slower processors or systems that have unsatisfactory real-time properties. Desirable is the steepest possible right-sided flank of the curve. Since this is a processor with a clock frequency of 2.5 GHz and thus a clock interval of 0.4 ns, a maximum latency of 40 µs would be permissible according to the above-mentioned rule of thumb. The measured value of 19µs is considerably lower, so that research into the causes of this latency and the attempt to achieve its further reduction are probably not meaningful.

Analysis of a system with unsatisfying real-time properties

The latency plot shown in Figure 2 is a Uniprocessor system with x86 architecture. This architecture often requires so-called System Management Interrupts (SMIs) with which, for example, certain communication protocols, thermal control measures, and microcode patches. Since the operating system has no way of preventing SMIs, it is quite possible that SMIs with an execution time longer than the acceptable latency of the system may lead to such a system not being able to be used for real-time tasks.
Sometimes, the manufacturer’s repair of the BIOS can eliminate or at least shorten the SMIs to such an extent that it does not interfere with the real-time properties of the system.

Inspired by a talk and slides of Dr. Carsten Embde

Источник

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

Существуют patch для real-time. Что они дают? Уменьшается ли временной квант для процессов? Появляются ли дополнительные возможности для управления жизнью процесса в системе?

Re: Что дает 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 удовольствием поделюсь тем что откапал [не думаю что этим вопросом многие занимаются].

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

Существуют несколько 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) позволяет рвать процессы в состоянии ядра.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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? вобщем-то это задержка, в любом словаре есть, но на практике — это время отклика системы

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

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?

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

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

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

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

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

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

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

Прошу прощения за навязчивость, но можно прокомментировать следующую фразу из 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. В обработчике таймера можно проделать опрос нужного девайса и по крайней мере засэйвить это состояние и время его опроса (те по крайней мере поступление событий всегда происходит в реальном времени). Если уж хочется реагировать на это событие — можно проделать это в обработчике (хотя это и плохой дизайн).
И я считаю что это очень хорошо — что эти действия не могут быть прерваны и вытеснены, если юзер захочет мышкой повозить, в чем вы пытаетесь меня убедить.

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

для начала уберем слово 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 куска кода в этом. форуме]

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

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

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

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.

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

ты ж сам в тексте используешь — «asynchronously» 😉

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

могу конечно с утра сморозить глупость, но 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: хотя все это догадки.

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

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

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

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

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
Т.е., процесс в ядре болтается больше, чем юзерспейсе.

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

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

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

Источник