Windows vs Linux - Как десктоп
, и игровая станция.
![]() |
Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
|
| ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
| [216.73.216.243] |
|
|
Правила раздела:
| Страницы: (1182) « Первая ... 743 744 [745] 746 747 ... 1181 1182 ( Перейти к последнему сообщению ) |
Windows vs Linux - Как десктоп
, и игровая станция.
|
Сообщ.
#11161
,
|
|
|
|
Ага, у меня, видимо, галлюцинации. А дома и на работе стоит, наверное, какая-нить древняя полуось ![]() Цитата linuxfan @ Надо намекать, почему приложение, страницы которого подгружаются из свопа, тормозит, или вы все-таки разбираетесь в пресловутом x86 на уровне более продвинутом, чем «Диспетчер устройств» Windows? Уж намекните, сделайте любезность. А то я что-то никак не пойму, почему этим не страдают форточки. Почему приложение, страницы которого вообще никто не трогает и трогать не может, вдруг начинает тормозить. Не пойму также, почему вдруг своп попал в разряд операций, на время которых необходимо блокировать прерывания (и конкретно - обмен данными с дисковой подсистемой для этого самого свопа). Цитата linuxfan @ О фанатизме виндузятнигов можно сказать ничуть не меньше, а о их самомнение, ежедневно укрепляемое «хакерскими» чистилками реестра и твикерами, можно сказать гораздо больше, чем о красноглазии приверженцев альтернативной ОС. Самомнение? Я пока наблюдаю прямо противоположную ситуацию. Даже глядя только на ваши сообщения. |
|
Сообщ.
#11162
,
|
|
|
|
Но не тут-то было. "Розарио Агро еще никто не называл тупым". Blue Soleil 3.2.2.8 с золотым ключиком спасло отца русской демократии.
Добавлено Итого: сижу в Висте, закачиваю на свой телефон файлы по Bluetooth. |
|
Сообщ.
#11163
,
|
|
|
|
Цитата wind @ Самомнение? Я пока наблюдаю прямо противоположную ситуацию. Даже глядя только на ваши сообщения. Ну еще бы! Это так почетно принадлежать к ничтожно малочисленной секте избранных-у-которых-линукс-работает. Моя пиписька ну просто раздуваеццо от гордости, когда я думаю об этом ![]() Цитата wind @ А то я что-то никак не пойму, почему этим не страдают форточки. Еще как страдают. WMP или винамп ни разу не заикался чтоли? ![]() Объясняю: обычная операция чтения/записи никак не влияет на исполнение процесса и его тредов, просто выполнение переходит в kernel mode, ну а там по обстоятельствам, в зависимости от того, будет ли IO синхронным или асинхронным. В ситуация с page swapping принципиально иная: ядро находится в обработчике события page fault и процесс (и ни одна его нить) не могут исполняться до завершения этого обработчика. |
|
Сообщ.
#11164
,
|
|
|
|
Цитата linuxfan @ Еще как страдают. WMP или винамп ни разу не заикался чтоли? Бывало в форточках, если они работали с диском через бивис. В 3.11-х, 95-х, 98-х. В NT - никогда такого не видел, хотя возможность допускаю. Ну а мышь-то причём? Цитата linuxfan @ В ситуация с page swapping принципиально иная: ядро находится в обработчике события page fault и процесс (и ни одна его нить) не могут исполняться до завершения этого обработчика. Правильно, процесс. Только тот (те) процесс(ы), память которых вымещена. А теперь вопрос на засыпку - какое к этому отношение имеет мышиный курсор или оболочка, память которых точно никто не трогал и трогать не собирается? |
|
Сообщ.
#11165
,
|
|
|
|
Цитата linuxfan @ WMP или винамп ни разу не заикался чтоли? ![]() Практически нет. А вот когда загружал бубунту с лайв цд, заходил на винт и открывал OGG, то слушать музыку было невозможно — одни прерывания. |
|
Сообщ.
#11166
,
|
|
|
|
Цитата Корпорация Microsoft проанализировала данные статистики по сбоям компьютеров, работающих под операционными системами семейства Windows (2000, XP и Vista). ага, видео дрова глючат Однако в первую очередь - это касаеться линукса, с непомерно раздутыми и мега глюкавыими иксами.. Одно врема пробовал стартануть GL QUAKE-I, с чистой консоли, получив не тока облом по полной - но и массу глюков с зависаниями (типичному явлению в мире *nix, на жалкие попытки кернелхакерства). Не надо ходить к шаману вуду, чтобы понять что гуй в линупсе также работает в режиме ядра, с кучей ламозных Ring3 прокладок, приводящим к залипаниям мыши и плохой прорисовке окон (вследствии не использования аппаратных возможностей видеокарты, а также закрытию некоторых кульных фич, доступных только в виндах ). Кстати сравнив бинарники драйверов винды и линукса можно убедиться, что доля программного кода используеться и там и там. По всей вероятности у Nvidia кроссплатформеные драйвера - за сорцы которые, оно повеситься, или заломит миллионы баксов, за то что в принципе нафик никому не надо - чисто для проформу или генту идеальной сборки (хотя до идеала там как до албании раком). |
|
Сообщ.
#11167
,
|
|
|
|
Цитата wind @ Правильно, процесс. Только тот (те) процесс(ы), память которых вымещена. А теперь вопрос на засыпку - какое к этому отношение имеет мышиный курсор или оболочка, память которых точно никто не трогал и трогать не собирается? Тут не в памяти дело а в процессоре. Движение мышиного курсора "отвлечет" процессор от обработки другого прерывания. Вообще логично, чтобы обработчик прерывания/исключения напрочь блокировал прерывания вплоть своего завершения. С процессами пользовательской среды также. Добавлено linuxfan, в винде вообще-то звуковой вывод буферизуется, и потому достаточно периодически пополнять такой буфер, а не постоянно следить за ним. Не знаю, как это реализовано, но при зависании ядра жто очень заметно - как зациклился буфер. |
|
Сообщ.
#11168
,
|
|
|
|
Я чего-то не понимаю: господа виндузятники упорно пытаются доказать, что черное — это белое, потому что им так сказали. Почитайте Танненбаума, что ли…
Цитата wind @ Правильно, процесс. Только тот (те) процесс(ы), память которых вымещена. А теперь вопрос на засыпку - какое к этому отношение имеет мышиный курсор или оболочка, память которых точно никто не трогал и трогать не собирается? В общем-то, все просто: если прерывания заблокированы, то их обработка откладывается. Соответственно, прерывания от PS/2 или USB тоже отложены. Есть опция при сборке ядра, которая контролирует, когда и насколько блокировать прерывания. Одно из значений (PREEMPT) подходит для десктопа, другое — для сервера. |
|
Сообщ.
#11169
,
|
|
|
|
Цитата Мяут @ Движение мышиного курсора "отвлечет" процессор от обработки другого прерывания. У процессора достаточно механизмов, благодаря которым это есть _штатный режим_ его работы. Цитата Мяут @ Вообще логично, чтобы обработчик прерывания/исключения напрочь блокировал прерывания вплоть своего завершения. С процессами пользовательской среды также. Нет, не логично. Особенно это касается прерываний, обслуживающий периферию - они вообще шарятся между устройствами. При чём тут процессы пользовательской среды, вообще не понимаю. Цитата mo3r @ В общем-то, все просто: если прерывания заблокированы, то их обработка откладывается. Соответственно, прерывания от PS/2 или USB тоже отложены. Ышо раз, объясните мне, тупому, зачем блокировать прерывания для выполнения операций, _не требующих_ блокировки прерываний? |
|
Сообщ.
#11170
,
|
|
|
|
Цитата wind @ Ну а мышь-то причём? При том, что заикание звука и дерганье мыши имеют одинаковые корни: callback на событие, контролируемое обработчиком IRQ, не был вызван, т. к. подгружались страницы адресного пространства приложения. Цитата wind @ А теперь вопрос на засыпку - какое к этому отношение имеет мышиный курсор или оболочка, память которых точно никто не трогал и трогать не собирается? А откуда такая уверенность, что часть иксов не засвопило? Добавлено Цитата Мяут @ linuxfan, в винде вообще-то звуковой вывод буферизуется, и потому достаточно периодически пополнять такой буфер, а не постоянно следить за ним. Не знаю, как это реализовано, но при зависании ядра жто очень заметно - как зациклился буфер. Он везде буферизуется. Это называется DMA, а IRQ приходит дважды: при проигрывании буфера до середины и при исчерпании буффера. Если ничего не предпринимать, то будет циклическое проигрывание буфера. Цитата wind @ Ышо раз, объясните мне, тупому, зачем блокировать прерывания для выполнения операций, _не требующих_ блокировки прерываний? А может надо взять какую-нибудь умную книжку, в которой умные дядьки расскажут про IRQ и почему при обработке прерывания таймера, прерывания от мыши приходить не будут (hint: все IRQ с большими или равным номерами блокируются, можно, конечно, разблокировать, только надо четко предствалять, к чему это приведет)? Вы пытаетесь рассуждать о том, о чем не имеете ни малейшего понятия. Впрочем, как я уже говорил выше, такое поведение для виндузятника вполне естественно -- он же асилил твикеры -- это же наверняка сложнее работы железа. |
|
Сообщ.
#11171
,
|
|
|
|
Цитата wind @ У процессора достаточно механизмов, благодаря которым это есть _штатный режим_ его работы. Цитата wind @ Ышо раз, объясните мне, тупому, зачем блокировать прерывания для выполнения операций, _не требующих_ блокировки прерываний? Это вопрос производительности системы. Обработка событий таким образом увеличивает общее быстродействие (за счет меньшего количества критических секций, блокировок, уменьшения использования механизмов синхронизации), но увеличивает время реакции системы. Получается некоторый выбор. Для интерактивных систем важно одно, для серверов — другое. Добавлено Цитата wind @ Вы просто открыли мне глаза! Оказывается, карточка nvidia geforce256, которая сидит у меня в системном блоке, называется ati! А убунту пробовали? В 7.04 при запуске появляется такое окошечко, которое говорит, что можно поставить дрова. Цитата https://help.ubuntu.com/community/BinaryDriverHowto/Nvidia As of Ubuntu 7.04 (Feisty Fawn) the recommended way to install the binary drivers is to use System → Administration → Restricted Devices Manager. This will try and choose the correct version out of nvidia-glx-legacy (which corresponds to the 71xx driver), nvidia-glx (which corresponds to the 96xx driver) and nvidia-glx-new (which at the time of writing corresponded to the 97xx driver) automatically |
|
Сообщ.
#11172
,
|
|
|
|
Цитата linuxfan @ При том, что заикание звука и дерганье мыши имеют одинаковые корни: callback на событие, контролируемое обработчиком IRQ, не был вызван, т. к. подгружались страницы адресного пространства приложения. Не вижу связи. Цитата linuxfan @ А откуда такая уверенность, что часть иксов не засвопило? Оттуда, что это крайне маловероятно, а главное - никак не должно влиять на мышиный драйвер. Цитата linuxfan @ А может надо взять какую-нибудь умную книжку, в которой умные дядьки расскажут про IRQ и почему при обработке прерывания таймера, прерывания от мыши приходить не будут (hint: все IRQ с большими или равным номерами блокируются, можно, конечно, разблокировать, только надо четко предствалять, к чему это приведет)? Вы пытаетесь рассуждать о том, о чем не имеете ни малейшего понятия. Я ржал чуть не полчаса над вашими острОтами mo3r, вы слегка в курсе, сколько при самых пессимистичных прогнозах, может обрабатываться прерывание таймера и с какой частотой возникают прерывания от устройств ввода? Вы в курсе, что ваше описание не соответствует действительности - блокируется лишь IRQ _с тем же приоритетом_, а все прочие лишь обрабатываются в соответствии с приоритетом? Вы в курсе, что любой обработчик _в любом случае должен_ как можно быстрее выдать "конец прерывания" в контроллер, ибо прерывания шарятся? Вы бы чуть-чуть думали, прежде чем ляпнуть очередное "не осилил" или "не имеете ни понятия". И прежде чем бросаться во все тяжкие, выдавая совершенно ненормальное поведение системы за вполне ожидаемое. Цитата mo3r @ Это вопрос производительности системы. Обработка событий таким образом увеличивает общее быстродействие (за счет меньшего количества критических секций, блокировок, уменьшения использования механизмов синхронизации), но увеличивает время реакции системы. В нормально спроектированной системе обработка прерываний драйверами и обработка событий службами/приложениями совсем не есть одно и то же. Хотите сказать, что линукс устроен иначе? Цитата mo3r @ А убунту пробовали? В 7.04 при запуске появляется такое окошечко, которое говорит, что можно поставить дрова. Посмотрим. Меня пока пугает отсутствие там (пока со слов советчиков) альтернативы Яста. Кстати, вы не ответили на мой вопрос - что там в качестве mta по дефолту и каким образом он конфигурируется? |
|
Сообщ.
#11173
,
|
|
|
|
Цитата wind @ Оттуда, что это крайне маловероятно, а главное - никак не должно влиять на мышиный драйвер. Кхм... во-первых, кто мышкой-то управляет? Цитата wind @ mo3r, вы слегка в курсе, сколько при самых пессимистичных прогнозах, может обрабатываться прерывание таймера и с какой частотой возникают прерывания от устройств ввода? Вы в курсе, что ваше описание не соответствует действительности - блокируется лишь IRQ _с тем же приоритетом_, а все прочие лишь обрабатываются в соответствии с приоритетом? Вы в курсе, что любой обработчик _в любом случае должен_ как можно быстрее выдать "конец прерывания" в контроллер, ибо прерывания шарятся? Я уже устал повторять. Некоторые части кода ядра заключены в критические секции, в которых происходит блокирование прерываний. Поэтому их обработка откладывается. Это так сложно понять? Цитата wind @ Вы бы чуть-чуть думали, прежде чем ляпнуть очередное "не осилил" или "не имеете ни понятия". И прежде чем бросаться во все тяжкие, выдавая совершенно ненормальное поведение системы за вполне ожидаемое. Это к вам относится, в первую очередь. Кстати, в определенных условиях это поведение и является вполне ожидаемым. Цитата wind @ В нормально спроектированной системе обработка прерываний драйверами и обработка событий службами/приложениями совсем не есть одно и то же. Хотите сказать, что линукс устроен иначе? Эх... Я говорю про блокировку прерываний, а вы про IRQ... Но суть в том, что события вызываются прерываниями, которые отложены. Цитата wind @ Меня пока пугает отсутствие там (пока со слов советчиков) альтернативы Яста Совершенно напрасно. Цитата wind @ Кстати, вы не ответили на мой вопрос - что там в качестве mta по дефолту и каким образом он конфигурируется? Не знаю, не интересовался. Добавлено Цитата wind @ Посмотрим. а как же тогда сразу вычеркнули его? Добавлено Цитата wind @ что там в качестве mta по дефолту и каким образом он конфигурируется? https://help.ubuntu.com/community/MailServer |
|
Сообщ.
#11174
,
|
|
|
|
Цитата wind @ Вы в курсе, что ваше описание не соответствует действительности - блокируется лишь IRQ _с тем же приоритетом_, а все прочие лишь обрабатываются в соответствии с приоритетом? Ядрен-батон, почитай факин мануалы! IRQ0 блокирует на контроллере IRQ0-IRQ15 (ну лана, -IRQ7, т. к. все знают, что 8-15 -- это каскад с IRQ2). IRQ1 блокирует на контроллере IRQ1-IRQ7 и т. д. Это конечно оффтоп, но прежде чем указывать другим на некомпетентность, неплохо бы проверить «а не лажаю ли я сам». Дальше: когда процесс находится в состоянии сваппинга, его выполнение блокируется. Началась выгрузка страниц X server'а из-за нехватки памяти -- все, курсор засирает, но IRQ от крысы все равно приходят. А свидетельство этому -- то что курсор дергается. Если бы на время своппинга блокировались IRQ, то скачков курсора не было бы -- он бы двигался плавно. |
|
Сообщ.
#11175
,
|
|
|
|
Цитата mo3r @ Кхм... во-первых, кто мышкой-то управляет? Мышкой управляет драйвер. Пользовательский код загружает курсоры, скрывает/показывает, позиционирует (в тех случаях, когда необходимо вполне определённое положение курсора мыши). Цитата mo3r @ Я уже устал повторять. Некоторые части кода ядра заключены в критические секции, в которых происходит блокирование прерываний. Поэтому их обработка откладывается. Это так сложно понять? Сложно понять - нафига. Не вижу ничего пользительного в таком хищническом использовании ресурсов. Цитата mo3r @ Это к вам относится, в первую очередь. Кстати, в определенных условиях это поведение и является вполне ожидаемым. Да ну? Ну что же, расскажу, чего ожидаю. После включения компьютера и загрузки оболочки я запускаю некоторое число софтин, небходимых для работы. Просто нажимаю на все соответствующие кнопочки в панели быстрого запуска. Первым открываю ФАР и запускаю копирование с флэшки (что дома сделал); в это самое время запущенные мною программы загружаются. За сим иду пить утренний кофэ - всё это хозяйство загружается довольно долго. Это, как вы понимаете, в форточках. Теперь то же самое в линуксе. После запуска оболочки запускаю первую софтину. Дожидаюсь отмерзания курсора мыши и запускаю следующую. И так далее. Вот это есть совершенно ненормально. Цитата mo3r @ Эх... Я говорю про блокировку прерываний, а вы про IRQ... Но суть в том, что события вызываются прерываниями, которые отложены. Ещё смешнее. Маскировать прерывания из обработчика аппаратного прерывания - это совсем уж ни в какие ворота не лезет (маскировка выполняется ручками, а не сама собой). Хорошо, даже если всё так "хорошо продумано", то на сколько? На несколько десятков тактов? Цитата mo3r @ а как же тогда сразу вычеркнули его? Посмотрите, из чего вычеркнул. Залипание мыши я в Убунте наблюдал (не у себя - на машинке сослуживца). Так же и в opensuse. Только дебиан и федора пока отличились - там этот феномен я наблюдаю только в первые несколько минут работы и при большом числе загруженных приложений. Добавлено Цитата linuxfan @ Ядрен-батон, почитай факин мануалы! IRQ0 блокирует на контроллере IRQ0-IRQ15 (ну лана, -IRQ7, т. к. все знают, что 8-15 -- это каскад с IRQ2). IRQ1 блокирует на контроллере IRQ1-IRQ7 и т. д. Это конечно оффтоп, но прежде чем указывать другим на некомпетентность, неплохо бы проверить «а не лажаю ли я сам». Почитайте лучше сами. Не блокирует, а обрабатывается первым. Блокировка - суть потеря события, это происходит только с IRQ того же приоритета до команды "конец прерывания". Цитата linuxfan @ Дальше: когда процесс находится в состоянии сваппинга, его выполнение блокируется. Началась выгрузка страниц X server'а из-за нехватки памяти -- все, курсор засирает, но IRQ от крысы все равно приходят. А свидетельство этому -- то что курсор дергается. Если бы на время своппинга блокировались IRQ, то скачков курсора не было бы -- он бы двигался плавно. Процесс никаким боком с драйвером мыши пересекаться не может. Ни разу. Не должен, по крайней мере. А рывки курсора означают только одно - часть событий от мыши проигнорирована. |