>[оверквотинг удален]
>> Собственно этот режим и предлагает kmscon:
>> shell -> kmscon. Тоесть отвечая на свой вопрос ДА.
>> 3. Нет.
>> PS. Я имел ввиду не юзерспейс-ядерный контекст, а переключение
>> задач, что накладней. Сорри, за путаницу.
> Вы же, по-моему, понимаете, что переключение контекстов происходит не на каждый символ,
> а на каждый вызов fflush из stdio.h или подобного вызова из
> подобной библиотеки. Никто не откючает юзерспейс-буферизацию. По-умолчанию (glibc'овые
> настройки буферизации для stdin/stdout/stderr), переключения контекстов происходят
> на каждую выведенную строчку.stderr - no
>[оверквотинг удален]
> эмулятором терминала пользуетесь. Выпишите все эти цифры, посмотрите на них, и
> подумайте, что же всё-таки больше тормозит систему: переключения контекстов или ядерная
> реализация виртуальной консоли.
> 1. В ядро никто не будет пихать кучу сложностей для того, чтобы
> сделать консоль быстрее: для консоли скорость важнее надёжности. Кроме того под
> каждую видеокарту придётся писать свой набор "сложностей".
> 2. Переключения процессов происходят не на каждый символ, и даже не на
> каждый fflush: fflush приводит лишь к сбросу юзерспейс-буфера в ядро. Будет
> ли ядро (получив управление через write) переключать задачи или подождёт когда
> в ядерном буфере накопится побольше?
Как настроишь так и будет.
> Принудительное переключение процессов происходит
Когда планировщик решит, баста какрапузики пора.
> лишь тогда, когда ядерный буфер переполняется и без освобождения буфера невозможно
> выполнить write.
Просходит shedule() и wait event текущего процесса.
> Ну, либо по таймеру.
> Всё это вместе говорит о
> том, что не стоит так бездумно рассуждать о прямопропорциональной зависимости количества
> переключений контекстов от количества выводимых символов. Всё несколько хитрее.
А кто и где рассуждал?
Я, лишь хотел узнать, как это реализовано?
PS. Не надо выкать, когда начал тыкать.
