Какие возможности в линуксе для реализации максимального реалтайма процесса?

Процесс читает данные из диска/сети?
Если читает из диска, поместить данные в ТМПФС, синхронизировать, например, по крону.

Что делает процесс?

Но, может, есть что-нибудь ещё? :)

Проц по мощнее.

Если читает из диска, поместить данные в ТМПФС

зачем?

Если читает из диска, поместить данные в ТМПФС

зачем?

Если интенсивно и часто читает данные, увеличится скорость.
Если ТС меняет nice чтоб быстрее работало, то это увеличит скорость.

ему не нужна скорость, ему нужен реалтайм

нет таких реалтаймовых задач, которые бы фейлились из-за io, если конечно чтение не идёт с дискеты или если не нужно читать гигабайты данных в секунду

chrt

Всякие RT и псевдо-RT надо обеспечивать для начала на уровне приложения, а не операционки. Толку от твоих настроек, если приложение будет лезть в базу и застревать там на 5 секунд?

RTLinux и Xenomai не предлагать

Патч -rt? Хотя, конечно, зависит от временнЫх требований задачи - может быть, просто задрать приоритет до FIFO и разумно спроектировать rt-часть.

CFQ с заданием RT для этого процесса

Не вижу смысла.

Эта... Реалтайм - это не мгновенная реакция на прерывание, а гарантированное время этой реакции. Оно может быть вполне приличным, а общее быстродействие даже может быть ниже, чем не-реалтайм.

Нет в линуксе такого и не будет никогда.

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

RTLinux и Xenomai не предлагать, мне нужно решение вообще без изменения кода.

ССЗБ

В промышленности используют специализированные решения всегда. Только идиоты или неимущие ресурсов на такое дело не используют специализированные решения.

Ещё -rt ядро.

А вот этого я не заметил:

RTLinux и Xenomai не предлагать, мне нужно решение вообще без 
изменения кода.

Покупайте уже QNX!

Реалтайм - это не мгновенная реакция на прерывание, а гарантированное время этой реакции

одно другому не мешает

Кнопку Power уже предлагали?

опишите работу приложения , пожалуйста.

одно другому не мешает

Хех, ещё как мешает. Чудес не бывает, М.Ч., увы. Если бы не мешало, все операционные системы были бы давно RTOS. Так что дибо быстрая (в большистве случаев) реакция, либо детерменированность реакции (гарантированное время).

Патч -rt?

но rt-часть приложения полностью должна быть заново переписана?

просто задрать приоритет до FIFO

объясните, пожалуйста, между чем и чем у Вас FIFO? :)

Патч -rt?

но rt-часть приложения полностью должна быть заново переписана?

Ответ на этот вопрос не зависит от использования -rt.

объясните, пожалуйста, между чем и чем у Вас FIFO? :)

Между нитями.

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

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

Может сначала посмотришь в сторону sched_setscheduler с SCHED_FIFO? Вдруг оно тебя устроит.

эм, господа, вы меня не совсем правильно поняли

Это потому, что ты плохо объясняешь.

я хочу сделать так, чтобы если какое-нибудь сраное приложение начнет грузить проц, а другое - жрать хард, чтобы эта программа (для ЧПУ) обработалась без каких-либо задержек.

cgroups, не? http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt

чтобы эта программа (для ЧПУ) обработалась без каких-либо задержек

nice --20 не достаточно?

что будет, если нить уровня ядра (бажное ядро, например) начнет жрать проц

А что, были прецеденты?

были. с подвисанием при использовании tar'а 100% загрузкой проца тредом ведра. причём решилось только более новым ведром. какого хрена оно случалось в ведре, не понятно. хочу заметить, что это был именно баг ведра, т.е. даже при 10кб архиве даже за полчаса ничего хорошего не происходило

ага, судя по описанию ( http://www.opennet.ru/cgi-bin/opennet/man.cgi?topic=sched_setscheduler&ca... ) - это то, что мне нужно. устанавливается через chrt ( http://www.opennet.ru/man.shtml?topic=chrt&category=1&russian=2 )

вот ещё более кашерный манул http://www.cyberciti.biz/faq/howto-set-real-time-scheduling-priority-process/

так тебе приоритеты задать или рт надо?
если приоритеты, то кури nice/renice + ionice + schedtool
последний позволяет много чего, в том числе привязать процесс к ядру, задать планировщик и т.д.
на фоне schedtool chrt выглядит как-то смешно

P.S. RTLinux не предлагать,
мне нужно решение вообще без изменения кода.

Шашечки или ехать? Ты ещё морковку без каротина попроси. Для жесткого realtime есть rt-ядра. Зачем дуру то валяешь?

^______________^ это именно то, что надо.

Нет в линуксе такого и не будет никогда.

тут из зала подсказують, что размер rt-патча всё меньше с каждым релизом. к чему бы ето

к тому, что в ведре уже много всего

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

кстати, а раньше все эти вещи SCHED_FIFO, SCHED_RR, SCHED_BATCH, SCHED_ISO, SCHED_IDLEPRIO были только в rt- ? в чём на данный момент главное отличие от ванильного?

а bfs с schedtool будет работать?

Должен, вопрос лишь в том - как. Использование bfs само по себе может вызвать проблемы, поэтому никто ничего не гарантирует.

Все равно настоящий realtime не совместим с ОС общего назначения.

я понимаю, но у меня не космическая промышленность же :)