Windows vs Linux - Как десктоп , и игровая станция.

Цитата wind @ 14.08.07, 08:43

Теперь то же самое в линуксе. После запуска оболочки запускаю первую софтину. Дожидаюсь отмерзания курсора мыши и запускаю следующую. И так далее. Вот это есть совершенно ненормально.

Опять за старое? В Linux курсор застывает _очень_ редко. Запуск любого софта в категорию причин застывания курсора _не_входит_. Придумываем проблему и начинаем на неё жаловаться...

Цитата kuzja @ 14.08.07, 08:53

Опять за старое? В Linux курсор застывает _очень_ редко. Запуск любого софта в категорию причин застывания курсора _не_входит_.

А у нас со Смайком и Ромтеком, как обычно, коллективные галлюцинации

Цитата wind @ 14.08.07, 08:43

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

Неверно. Драйвер режима ядра (тот, что обрабатывает прерывания), посылает события движения мышки. Далее драйвер input device'а в X-сервере обрабатывает эти движения и решает, куда поставить курсор.

Цитата wind @ 14.08.07, 08:43

Сложно понять - нафига. Не вижу ничего пользительного в таком хищническом использовании ресурсов.

Это оптимальное использование ресурсов.

Цитата wind @ 14.08.07, 08:43

Теперь то же самое в линуксе. После запуска оболочки запускаю первую софтину. Дожидаюсь отмерзания курсора мыши и запускаю следующую. И так далее. Вот это есть совершенно ненормально.

После запуска оболочки запускаю сразу десяток софтин. Они запускаются. Теперь тоже самое в винде. Дожидаюсь отмерзания курсора, пытаюсь открыть пуск, а он не открывается. И так каждый раз.

Цитата wind @ 14.08.07, 08:43

Ещё смешнее. Маскировать прерывания из обработчика аппаратного прерывания - это совсем уж ни в какие ворота не лезет (маскировка выполняется ручками, а не сама собой). Хорошо, даже если всё так "хорошо продумано", то на сколько? На несколько десятков тактов?

Кхм... откуда вы это взяли? Код ядра входит в критическую секцию, и прерывания его не беспокоят. При чем обработчики аппаратных прерываний?

Добавлено 14.08.07, 09:13

Цитата kuzja @ 14.08.07, 08:53

Опять за старое? В Linux курсор застывает _очень_ редко.

У меня он вообще не застывал никогда У меня галлюцинации, наверное.

Цитата wind @ 14.08.07, 08:43

Ещё смешнее. Маскировать прерывания из обработчика аппаратного прерывания - это совсем уж ни в какие ворота не лезет (маскировка выполняется ручками, а не сама собой). Хорошо, даже если всё так "хорошо продумано", то на сколько? На несколько десятков тактов?

1. на входе в обработчик прерывания автоматом очищается IF
2. контроллер прерываний при поступлении IRQ самостоятельно блокирует все менее приоритетные прерывания, эта блокировка никак не связана с IF, для ее снятия надо самостоятельно дать контроллеру команду завершения обработки прерывания (EOI).

Цитата wind @ 14.08.07, 08:55

А у нас со Смайком и Ромтеком, как обычно, коллективные галлюцинации

Скорей, самовнушение...

Цитата linuxfan @ 14.08.07, 09:16

1. на входе в обработчик прерывания автоматом очищается IF
2. контроллер прерываний при поступлении IRQ самостоятельно блокирует все менее приоритетные прерывания, эта блокировка никак не связана с IF, для ее снятия надо самостоятельно дать контроллеру команду завершения обработки прерывания (EOI).

1. Контроллер прерываний не блокирует менее приоритетные запросы во время обработки более приоритетного.
2. Время работы любого обработчика прерывания по сравнению с описанными задержками ничтожно мало.

Так понятно?

Цитата mo3r @ 14.08.07, 09:11

Неверно. Драйвер режима ядра (тот, что обрабатывает прерывания), посылает события движения мышки. Далее драйвер input device'а в X-сервере обрабатывает эти движения и решает, куда поставить курсор.

Что именно неверно? И где хоть в одном, хоть в другом описании можно увидеть какой-то гуёвый процесс?

Цитата mo3r @ 14.08.07, 09:11

Это оптимальное использование ресурсов.

То есть создание блокировок там, где они ни разу не нужны, отныне следует считать оптимальным использованием ресурсов?

Цитата mo3r @ 14.08.07, 09:11

Кхм... откуда вы это взяли? Код ядра входит в критическую секцию, и прерывания его не беспокоят. При чем обработчики аппаратных прерываний?

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

Сообщение отредактировано: wind - 14.08.07, 10:55

Цитата wind @ 14.08.07, 10:48

Что именно неверно?

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

Цитата wind @ 14.08.07, 10:48

То есть создание блокировок там, где они ни разу не нужны, отныне следует считать оптимальным использованием ресурсов?

Они там нужны. Но есть возможность (та самая опция PREEMPT) создать больше точек, где возможно приостановить работу и обработать всякие события или же сделать почти весь код реентерабельным. Но это, очевидно, более затратно, чем просто одна блокировка на критическую секцию. А создание блокировок просто увеличивает время реакции системы.

Цитата wind @ 14.08.07, 10:48

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

Имеем место несколько вещей. Одна, и самая важная — планировка процессов (тогда иксы не получают вовремя достаточного количества процессорного времени и не успевают обработать). Вот как раз временем отклика и (косвенно) управляет опция PREEMPT. А у вас она специально выставлена на большее время отклика системы, а вы никак не хотите признать того факта, что проблема только в том, что такое поведение и было выбрано (кем уж, не знаю — вы так и не сказали, в какой версии какого дистра такое наблюдается).

Цитата mo3r @ 14.08.07, 11:02

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

Вы противоречите сами себе. Я сказал - управляет драйвер (описав форточный драйвер), вы сказали - управляет драйвер (уточнив, что в линуксе есть драйвер ядра и драйвер x-сервера). И теперь говорите, что драйвер всё же не управляет ничем

Цитата mo3r @ 14.08.07, 11:02

Они там нужны.

Как мы коллективными усилиями выяснили, наиболее вероятной причиной залипания крысиного носа является своп. Для свопа блокировка пользовательского ввода вроде как не нужна. Есть что-то ещё?

Цитата mo3r @ 14.08.07, 11:02

Одна, и самая важная — планировка процессов (тогда иксы не получают вовремя достаточного количества процессорного времени и не успевают обработать). Вот как раз временем отклика и (косвенно) управляет опция PREEMPT. А у вас она специально выставлена на большее время отклика системы, а вы никак не хотите признать того факта, что проблема только в том, что такое поведение и было выбрано (кем уж, не знаю — вы так и не сказали, в какой версии какого дистра такое наблюдается).

1. Недостаточно времени для исполнения драйвера вследствие большого количества прожорливых пользовательских процессов - это я не понимаю. Это как-то неправильно.
2. Я не имею ни малейшего представления, во что у меня установлена опция PREEMPT - не трогал. Нигде в конфигурящих утилитах я не ставил крыжа навроде "чихать на приложения, отдавать приоритет системным процессам".
3. Наблюдается на opensuse_10, debian_4, fedora_7, ubuntu_не_знаю_какая_версия_так_как_не_на_моей_машинке. Я это не только не "не сказал", а повторял уже раза три, разве что без циферок.

Цитата wind @ 14.08.07, 11:41

Вы противоречите сами себе. Я сказал - управляет драйвер (описав форточный драйвер), вы сказали - управляет драйвер (уточнив, что в линуксе есть драйвер ядра и драйвер x-сервера). И теперь говорите, что драйвер всё же не управляет ничем

Не вижу противоречия. Драйвер только доставляет события от устройства и управляет устройством. Собственно положением курсора управляет x-сервер (на этот раз используя другой драйвер, не драйвер мыши).

Цитата wind @ 14.08.07, 11:41

Как мы коллективными усилиями выяснили, наиболее вероятной причиной залипания крысиного носа является своп.

Хм. Точно?

Цитата wind @ 14.08.07, 11:41

Для свопа блокировка пользовательского ввода вроде как не нужна.

Это наверняка?

Цитата wind @ 14.08.07, 11:41

1. Недостаточно времени для исполнения драйвера вследствие большого количества прожорливых пользовательских процессов - это я не понимаю. Это как-то неправильно.

Причина не в этом. Причина в том, что наверняка не включен DMA у устройств ввода-вывода и не установлено preempt, в результате чего ядро не отдает процессорное время. Достаточно убрать одну из причин. Но, как я говорил, этим занимается не пользователь, а дистростроитель.

Цитата wind @ 14.08.07, 11:41

2. Я не имею ни малейшего представления, во что у меня установлена опция PREEMPT - не трогал. Нигде в конфигурящих утилитах я не ставил крыжа навроде "чихать на приложения, отдавать приоритет системным процессам".

Дистр такой.

Цитата wind @ 14.08.07, 11:41

3. Наблюдается на opensuse_10, debian_4, fedora_7, ubuntu_не_знаю_какая_версия_так_как_не_на_моей_машинке. Я это не только не "не сказал", а повторял уже раза три, разве что без циферок.

Точно? Смотрел на opensuse 10.1, suse 9.3, ubuntu 6.10, ubuntu 7.04, slackware, gentoo…

В общем, кто-нибудь из виндузятников объяснит мне причину тормозов и дерганности курсора в винде при компиляции больших проектов в студии (комп мощный, dma включено, все дрова стоят)?

Добавлено 14.08.07, 12:01

Цитата wind @ 14.08.07, 11:41

разве что без циферок.

Это ключевой момент

Цитата wind @ 14.08.07, 11:41

Как мы коллективными усилиями выяснили, наиболее вероятной причиной залипания крысиного носа является своп.

Не своп, а критически малое количество свободной памяти. Это когда своп и оператива забиты до отказа. Вот в таком случае у меня начинал тормозить курсор, в прочем, как и всё остальное. Было это всего пару раз, когда с эклипсом баловался
А ещё у меня курсор притормаживал, когда я юзал берил. Там действительно на ресурсоёмких операциях были заметны подёргивания.
Давайте уже закончим эту тему, а то она превратится в ещё один "вимовский интерфейс"

Гы, не ссорьтесь
http://www.securitylab.ru/news/301038.php

Цитата mo3r @ 14.08.07, 12:00

Это наверняка?

Наверняка

Цитата mo3r @ 14.08.07, 12:00

Причина в том, что наверняка не включен DMA у устройств ввода-вывода и не установлено preempt, в результате чего ядро не отдает процессорное время.

DMA точно включен. Во всех случаях.

Цитата mo3r @ 14.08.07, 12:00

Хм. Точно?

Нет, конечно. Просто форточникам никто не верит, а из линуксятников пока только linuxfan высказался.

Цитата mo3r @ 14.08.07, 12:00

и не установлено preempt, в результате чего ядро не отдает процессорное время

Цитата kuzja @ 14.08.07, 12:10

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

Определимся?

Цитата wind @ 14.08.07, 12:27

Определимся?

а условие вида

Цитата

и не установлено preempt

о чём-то говорит?

Цитата kuzja @ 14.08.07, 12:31

о чём-то говорит?

Ровным счётом ни о чём не говорит. Точнее, mo3r говорит, что это что-то связанное со стратегией распределения процессорного времени. А вы говорите о памяти. Кого слушать?

Цитата wind @ 14.08.07, 10:48

1. Контроллер прерываний не блокирует менее приоритетные запросы во время обработки более приоритетного.

А я говорю, блокирует. В дестстве читал книжку Зубкова «Assebler для DOS, Windows, Unix», где русским по белому было написано, что во время обработки IRQx на контроллере IRQy, где y >= x заблокированы.

Цитата wind @ 14.08.07, 10:48

2. Время работы любого обработчика прерывания по сравнению с описанными задержками ничтожно мало.

А я и не отрицаю, что обработка IRQ к «замиранию» крысиного курсора не имеет особого отношения.

Цитата wind @ 14.08.07, 11:41

Для свопа блокировка пользовательского ввода вроде как не нужна. Есть что-то ещё?

Да. Блокировка процесса, который свопится. Драйвера X сервера выполняются в user mode со всеми вытекающими.

Цитата wind @ 14.08.07, 11:41

1. Недостаточно времени для исполнения драйвера вследствие большого количества прожорливых пользовательских процессов - это я не понимаю.

Пойми, курсор отрисовывается X сервером, который суть user-mode приложение.