высокоприоритетная консоль для gui

нет таких!
если ввод-вывод повис, то как ты хочешь получить, точнее послать сигнал, терминал?
чини 12309

подозреваю, что висит в основном kswapd

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

>kswapd
блин, может проще оперативки прикупить?))

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

проблема в том, что универсального средства от 12309 нету)

>> блин, может проще оперативки прикупить?

Стоит попробовать.

проблема в том, что универсального средства от 12309 нету)

Это не значит, что нельзя пробовать не универсальные. Начни отсюда: http://www.linux.org.ru/wiki/en/User:shimon/12309

>ускорить обработку хоткеев, не поднимая приоритет всему DE

- Пишем демона, кот-й читает клавиатуру напрямую из /dev/input/by-path/*kbd*
- nice -20 ...
- ...
- Profit

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

>получить, точнее послать сигнал

Не нужно.

>Это не значит, что нельзя пробовать не универсальные
ну, всё равно нет гарантий, что поможет. ситуации всё-таки у меня возникали разные. и kswapd, и convert, и firefox... в основном, конечно, упирается в io.
да даже если и поможет, вопрос темы всё равно будет актуален :)
спасибо за ссылку, в фак я хоть и заглядывал, но исключительно по теме.

ээх, вспоминаю я былые времена под softice-ом)

опа - а как ты хочешь сообщить компу о желании заиметь терминал в обход ввода-вывода? о_О

>Пишем демона
интересно!
я подумывал о каком-нибудь драйвере, который бы вклинивался во фрейм-буфер.

подсистема устройств ввода в самом ядре будет иметь слишком низкий приоритет

резонно. хотя прерывания с клавиатуры должны обрабатываться сразу, они поступают сначала в буфер. а его уже ядро раскладывает процессам чуть после.
надо глянуть исходники ядра, что он выдает в /dev/input/, если нужный буфер, то демон с -20 должен помочь.

>они поступают сначала в буфер
они - скан-коды клавиш)

сигнал != ввод-вывод
man signal

да, но сигналы тоже будут ждать

Именно для графической консоли задача практически неразрешима (ну и по крайней мере придется поднимать приоритет X-серверу).

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

>придется поднимать приоритет X-серверу

В каких-то zen-ядрах так и сделано

Тем, кому вдруг интересно:
аптайм 18 дней. (т.е. до сих пор не перезагружался)
система не глючила, но и во времена очень большой нагрузки консоль выскакивала по 2-5 секунд. тем не менее считаю это хорошим результатом.
но теперь уж точно буду фиксить 12309.

хорошим результатом? о_О
да это ппц!
ман приоритеты!

нет!
там просто используется другой планировщик
учи матчасть!

>там просто используется другой планировщик

Там приоритет Xorg'у поднят. Читай код, а не только лор.

там SCHED_ISO
вот и всё
а по поводу приоритета - достаточно моих костылей

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

if [[ `ps h -p $PPID -o cmd` == guake* ]]
then
sudo renice -20 $$ $PPID `pidof Xorg nautilus`
sudo ionice -c 1 -n 0 -p $$ $PPID `pidof Xorg nautilus`
fi

да ничего особо
только что-то сильно избирательно у тебя
я сделал проще http://optimization.hardlinux.ru/?page_id=98#comment-445
да - pgrep юзабельней pidof-а

как вариант вижу только сделать все процессы unswappable и поменять их scheduling policy.
в любом случае то, для чего всё это затевалось, всё не работает.
надо фиксить 12309. без него точно не заработает. и памяти купить))

смотри выше

>Пишем демона, кот-й читает клавиатуру напрямую из /dev/input/by-path/*kbd*
Ты про actkbd?