The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Выпуск systemd 217 c реализацией консоли в пространстве поль..., opennews (??), 29-Окт-14, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


56. "Выпуск systemd 217 c реализацией консоли в пространстве поль..."  –1 +/
Сообщение от izykemail (ok), 29-Окт-14, 17:21 
>> Если у меня однопроцессорная система, то, вывод каждого символа, будет переключать контекст?
> А сейчас у тебя на каждый символ выполняется переключение контекста? А xterm
> требует на каждый символ переключения контекста? А приложение выполняющее графический
> вывод в framebuffer переключает юзерспейс-контекст в ядерный и обратно на каждый
> выводимый пиксель?

1. Если в текстовой консоле - нет.
2. На 1 CPU иногда и больше: shell -> xterm -> xorg.
   Ну один точно shell -> xterm. Если этот символ '\n'.
   или терминал в RAW.
   Собственно этот режим и предлагает kmscon:
   shell -> kmscon. Тоесть отвечая на свой вопрос ДА.
3. Нет.

PS. Я имел ввиду не юзерспейс-ядерный контекст, а переключение
задач, что накладней. Сорри, за путаницу.

Ответить | Правка | Наверх | Cообщить модератору

63. "Выпуск systemd 217 c реализацией консоли в пространстве поль..."  +1 +/
Сообщение от Аноним (-), 29-Окт-14, 18:29 
> имел ввиду не юзерспейс-ядерный контекст, а переключение задач, что накладней

Промолчал бы - сошёл бы за умного.

Ответить | Правка | Наверх | Cообщить модератору

65. "Выпуск systemd 217 c реализацией консоли в пространстве поль..."  +2 +/
Сообщение от Orduemail (ok), 29-Окт-14, 18:49 
>[оверквотинг удален]
> 1. Если в текстовой консоле - нет.
> 2. На 1 CPU иногда и больше: shell -> xterm -> xorg.
>    Ну один точно shell -> xterm. Если этот символ
> '\n'.
>    или терминал в RAW.
>    Собственно этот режим и предлагает kmscon:
>    shell -> kmscon. Тоесть отвечая на свой вопрос ДА.
> 3. Нет.
> PS. Я имел ввиду не юзерспейс-ядерный контекст, а переключение
> задач, что накладней. Сорри, за путаницу.

Вы же, по-моему, понимаете, что переключение контекстов происходит не на каждый символ, а на каждый вызов fflush из stdio.h или подобного вызова из подобной библиотеки. Никто не откючает юзерспейс-буферизацию. По-умолчанию (glibc'овые настройки буферизации для stdin/stdout/stderr), переключения контекстов происходят на каждую выведенную строчку. В сложных же случаях (например, вывод через ncurses) буферизация происходит сложнее, и эти сложности отражаются на прикладном коде, который использует ncurses.

Я отмечу, между прочим, что я давно переключился с работы в консоли на иксовые эмуляторы терминалов, потому что они меньше нагружают процессор. Когда я только познакомился с линуксом, меня пёрло сидеть именно в консоли, потому что ностальгия и синдром утёнка -- мой первый опыт общения с компьютером прошёл в текстовом режиме. Но и тем не менее я пользовался X'ами, и со временем заметил такую особенность консоли -- что она может замедлить процесс компиляции пакета, просто потому что куча вывода в консоль. Вы можете проверить это элементарно:

cd /usr/src/linux/kernel
f=`ls -S | head -n 1`
time cat "$f"
sleep 1; time cat "$f"

Когда последнюю команду вгоните, нажмите Enter пока sleep работает и тут же тыкните в Alt-f2, подождите немного и вернитесь обратно. Можете затем, интереса ради, проделать то же самое в urxvt/xterm или каким там вы эмулятором терминала пользуетесь. Выпишите все эти цифры, посмотрите на них, и подумайте, что же всё-таки больше тормозит систему: переключения контекстов или ядерная реализация виртуальной консоли.

1. В ядро никто не будет пихать кучу сложностей для того, чтобы сделать консоль быстрее: для консоли скорость важнее надёжности. Кроме того под каждую видеокарту придётся писать свой набор "сложностей".
2. Переключения процессов происходят не на каждый символ, и даже не на каждый fflush: fflush приводит лишь к сбросу юзерспейс-буфера в ядро. Будет ли ядро (получив управление через write) переключать задачи или подождёт когда в ядерном буфере накопится побольше? Принудительное переключение процессов происходит лишь тогда, когда ядерный буфер переполняется и без освобождения буфера невозможно выполнить write. Ну, либо по таймеру. Всё это вместе говорит о том, что не стоит так бездумно рассуждать о прямопропорциональной зависимости количества переключений контекстов от количества выводимых символов. Всё несколько хитрее.

Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

70. "Выпуск systemd 217 c реализацией консоли в пространстве поль..."  –1 +/
Сообщение от izykemail (ok), 29-Окт-14, 20:34 
>[оверквотинг удален]
>>    Собственно этот режим и предлагает kmscon:
>>    shell -> kmscon. Тоесть отвечая на свой вопрос ДА.
>> 3. Нет.
>> PS. Я имел ввиду не юзерспейс-ядерный контекст, а переключение
>> задач, что накладней. Сорри, за путаницу.
> Вы же, по-моему, понимаете, что переключение контекстов происходит не на каждый символ,
> а на каждый вызов fflush из stdio.h или подобного вызова из
> подобной библиотеки. Никто не откючает юзерспейс-буферизацию. По-умолчанию (glibc'овые
> настройки буферизации для stdin/stdout/stderr), переключения контекстов происходят
> на каждую выведенную строчку.

stderr - no

>[оверквотинг удален]
> эмулятором терминала пользуетесь. Выпишите все эти цифры, посмотрите на них, и
> подумайте, что же всё-таки больше тормозит систему: переключения контекстов или ядерная
> реализация виртуальной консоли.
> 1. В ядро никто не будет пихать кучу сложностей для того, чтобы
> сделать консоль быстрее: для консоли скорость важнее надёжности. Кроме того под
> каждую видеокарту придётся писать свой набор "сложностей".
> 2. Переключения процессов происходят не на каждый символ, и даже не на
> каждый fflush: fflush приводит лишь к сбросу юзерспейс-буфера в ядро. Будет
> ли ядро (получив управление через write) переключать задачи или подождёт когда
> в ядерном буфере накопится побольше?

Как настроишь так и будет.

> Принудительное переключение процессов происходит

Когда планировщик решит, баста какрапузики пора.

> лишь тогда, когда ядерный буфер переполняется и без освобождения буфера невозможно
> выполнить write.

Просходит shedule() и wait event текущего процесса.

> Ну, либо по таймеру.
> Всё это вместе говорит о
> том, что не стоит так бездумно рассуждать о прямопропорциональной зависимости количества
> переключений контекстов от количества выводимых символов. Всё несколько хитрее.

А кто и где рассуждал?
Я, лишь хотел узнать, как это реализовано?

PS. Не надо выкать, когда начал тыкать.

Ответить | Правка | Наверх | Cообщить модератору

71. "Выпуск systemd 217 c реализацией консоли в пространстве поль..."  +/
Сообщение от Orduemail (ok), 29-Окт-14, 21:04 
> stderr - no

Точно.

>> Будет
>> ли ядро (получив управление через write) переключать задачи или подождёт когда
>> в ядерном буфере накопится побольше?
> Как настроишь так и будет.

Можно чуть подробнее -- о чём вы? Я предполагаю, но не уверен, а интересно.

>> лишь тогда, когда ядерный буфер переполняется и без освобождения буфера невозможно
>> выполнить write.
> Просходит shedule() и wait event текущего процесса.

Короче, происходит переключение процессов. ;)

> PS. Не надо выкать, когда начал тыкать.

Это простите великодушно. Реакция на местное тыкание вызывает естественное подражание, но привычка постоянно переключает обратно. Мне лично насрать, а вам?

Ответить | Правка | Наверх | Cообщить модератору

98. "Выпуск systemd 217 c реализацией консоли в пространстве поль..."  +/
Сообщение от izykemail (ok), 30-Окт-14, 11:05 

> Можно чуть подробнее -- о чём вы? Я предполагаю, но не уверен,
> а интересно.

http://linux.die.net/man/3/termios

Canonical and noncanonical mode:
MIN, TIME

Raw mode

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру