Здравствуйте, eqw, Вы писали:
eqw>>>Ну вот, а срач развели на кучу сообщений. N>>А кто развёл-то? eqw>Тот, кто пришеол и начал мне обьясняль, что я не понимаю, почему у линуксоидов тормозит GUI и зачем-то начал давать хинты про Wayland.
Нет, тот, кто влез в этот тред с (цитирую) "и получить такой же тормозящй гуй, как в линуксе? Спасибо, не надо." в ответ на замечание про ограничение количества дескрипторов (!) в виндовом GDI.
eqw>>>А для меня, например, одним из критериев качества является отзывчивость UI.
N>>С точностью до миллисекунд? Извиняй, товарищ Терминатор, не признал. Привет агенту Смиту. eqw>Визуально опознаваемая любым челвоеческим глазом, там счет на доли секунд, а не на миллисекунды.
Не существует ни на одной из систем, на которых я работал, начиная с, повторюсь, 486/50.
The God is real, unless declared integer.
Re[15]: Разработчик ядра Windows NT объяснил причины низкой производительности О
То есть фактически всё время это ожидание чего-то. Скорее всего, диска (надо бы для точности приложить результаты iostat и/или procinfo).
Да, больше всего похоже на пляски с журналом.
AB>Т.е. таки да, для EXT3 в условиях ограниченных ресурсов счет идет на минуты и все это время система что-то делает с диском.
Интересно бы посмотреть на список экстентов (размеры и расстояние между ними) в случае такого файла на ext4...
The God is real, unless declared integer.
Re[24]: Разработчик ядра Windows NT объяснил причины низкой производительности О
Здравствуйте, eqw, Вы писали:
eqw>В линуксе без нагрузки отзывчивость UI ниже, чем в виндах.
Как проверить?
>>>>Вот у меня есть линукс с гномом, окошки отрисовываются нормально, кино показывается, как понять, что у меня гуй тормозит? eqw>>>У вас все хорошо, зачем это вам?
MTD>>Ну тут говорят, что все плохо, я и захотел узнать — а вдруг и правда, а я не в курсе eqw>Да, вы правда не в курсе. Но зачем создавать себе проблему, если у вас все хорошо. Идите лучше, чайку попейте.
Аааа, ну так сразу бы и сказали, что фантазии свои рассказываете.
Re[20]: Разработчик ядра Windows NT объяснил причины низкой производительности О
Здравствуйте, eqw, Вы писали:
eqw>Мне плевать на ваш частный случай, если честно. Лично я вижу кучу людей спрашиваюших, почему UI responsiveness (ресайз окошек, прокрутка) у линукса медленнее, чем у windows и не вижу людей, спрашивающих наоборот.
Здравствуйте, netch80, Вы писали:
n> То есть фактически всё время это ожидание чего-то. Скорее всего, диска (надо бы для точности приложить результаты iostat и/или procinfo). n> Да, больше всего похоже на пляски с журналом.
Угу, шуршит дисками, которые, судя по времени dd, и так не особо быстрые. Хотя особого "фриза" системы (несмотря на взлет LA) в это время замечено не было — в соседнем терминале я вполне спокойно продолжал работать с системой в том же окружении.
n> Интересно бы посмотреть на список экстентов (размеры и расстояние между ними) в случае такого файла на ext4...
Если напишешь интересующую последовательность команд, то смогу повторить и предоставлю вывод. Хотя не думаю, что полученные результаты в данном треде будут иметь к-л практическую ценность
Здравствуйте, Anton Batenev, Вы писали:
AB>Угу, шуршит дисками, которые, судя по времени dd, и так не особо быстрые. Хотя особого "фриза" системы (несмотря на взлет LA) в это время замечено не было — в соседнем терминале я вполне спокойно продолжал работать с системой в том же окружении.
Конечно, если писать стометровыми блоками при наличии всего 256 метров оперативы. Это же надо память под стометровый буфер и память под кэш, которая будет вытеснять твой буфер в своп.
Пиши мегабайтными блоками. Или 4-8 мегабайтными, если oflags=direct
Проще всего создать стогиговый файл вызвав fallocate (на ext3 не реализовано). Если нет тулы, то hdparm умеет fallocate. По эффекту то же самое, но выполнится за пару секунд.
n>> Интересно бы посмотреть на список экстентов (размеры и расстояние между ними) в случае такого файла на ext4... AB>Если напишешь интересующую последовательность команд, то смогу повторить и предоставлю вывод. Хотя не думаю, что полученные результаты в данном треде будут иметь к-л практическую ценность
Тула — debugfs. Команда — dump_extents. Практической ценности — ноль.
При обычной конфигурации и свежей файловой системе это будет примерно 745 страниц метаданных, или 2.9 мегабайта. Не сравнить с тем, что приходится журанировать в ext3.
А вот если бы у тебя было ядро >= 3.2, то можно было бы создать фс с размером кластера скажем в один мегабайт, таким образом сократив скорость выделения/освобождения и количество метаданных раз так в 256.
Re[19]: Разработчик ядра Windows NT объяснил причины низкой производительности О
Здравствуйте, dimgel, Вы писали:
D>Мне плевать на твой запрос, если честно. Лично я у себя на машине вижу, что линукс существенно быстрее и отзывчивее восьмой винды.
Некоторые говорят, что НЛО видят.
Re[21]: Разработчик ядра Windows NT объяснил причины низкой производительности О
Здравствуйте, dimgel, Вы писали:
D>Здравствуйте, eqw, Вы писали:
eqw>>Мне плевать на ваш частный случай, если честно. Лично я вижу кучу людей спрашиваюших, почему UI responsiveness (ресайз окошек, прокрутка) у линукса медленнее, чем у windows и не вижу людей, спрашивающих наоборот.
D>Что, небось вопросы десятилетней давности, когда венда была ещё XP а KDE 4 только появился?
Нет, довольно свежие про современную убунту, например.
Re[27]: Разработчик ядра Windows NT объяснил причины низкой производительности О
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, eqw, Вы писали:
eqw>>>>Ну вот, а срач развели на кучу сообщений. N>>>А кто развёл-то? eqw>>Тот, кто пришеол и начал мне обьясняль, что я не понимаю, почему у линуксоидов тормозит GUI и зачем-то начал давать хинты про Wayland.
N>Нет, тот, кто влез в этот тред с (цитирую) "и получить такой же тормозящй гуй, как в линуксе? Спасибо, не надо." в ответ на замечание про ограничение количества дескрипторов (!) в виндовом GDI.
Я отвечал на сообщение, в котором кто-то, ней разбираясь в истории вопроса, предложил вынести gdi из ring0 дабы решить надуманную проблему.
eqw>>>>А для меня, например, одним из критериев качества является отзывчивость UI.
N>>>С точностью до миллисекунд? Извиняй, товарищ Терминатор, не признал. Привет агенту Смиту. eqw>>Визуально опознаваемая любым челвоеческим глазом, там счет на доли секунд, а не на миллисекунды.
N>Не существует ни на одной из систем, на которых я работал, начиная с, повторюсь, 486/50.
Я очень рад за вас да вот только мотив многочисленных однотипных вопросов на форумах ваш личный опыт выглядит мелковато.
Re[18]: Разработчик ядра Windows NT объяснил причины низкой производительности О
Здравствуйте, andrey.desman, Вы писали:
AB>>Угу, шуршит дисками, которые, судя по времени dd, и так не особо быстрые. Хотя особого "фриза" системы (несмотря на взлет LA) в это время замечено не было — в соседнем терминале я вполне спокойно продолжал работать с системой в том же окружении. AD>Конечно, если писать стометровыми блоками при наличии всего 256 метров оперативы. Это же надо память под стометровый буфер и память под кэш, которая будет вытеснять твой буфер в своп. AD>Пиши мегабайтными блоками. Или 4-8 мегабайтными, если oflags=direct
Я правильно понимаю, что без oflags=direct получим 12309?
n>>> Интересно бы посмотреть на список экстентов (размеры и расстояние между ними) в случае такого файла на ext4... AB>>Если напишешь интересующую последовательность команд, то смогу повторить и предоставлю вывод. Хотя не думаю, что полученные результаты в данном треде будут иметь к-л практическую ценность AD>Тула — debugfs. Команда — dump_extents. Практической ценности — ноль. AD>При обычной конфигурации и свежей файловой системе это будет примерно 745 страниц метаданных, или 2.9 мегабайта. Не сравнить с тем, что приходится журанировать в ext3.
Меня интересовали тут в первую очередь промежутки между экстентами.
AD>А вот если бы у тебя было ядро >= 3.2, то можно было бы создать фс с размером кластера скажем в один мегабайт, таким образом сократив скорость выделения/освобождения и количество метаданных раз так в 256.
У меня на десктопе OpenSuSE 12.2 с ядром 3.4.33.
man mke2fs продолжает говорить, что block size не подымается выше 4096. Слова cluster она не знает.
В доке по ext4 явно сказано, что ситуацию, когда block size больше VM page size, оно не поддерживает.
The God is real, unless declared integer.
Re[21]: Разработчик ядра Windows NT объяснил причины низкой производительности О
Здравствуйте, andrey.desman, Вы писали:
AD>Здравствуйте, eqw, Вы писали:
eqw>>Мне плевать на ваш частный случай, если честно. Лично я вижу кучу людей спрашиваюших, почему UI responsiveness (ресайз окошек, прокрутка) у линукса медленнее, чем у windows и не вижу людей, спрашивающих наоборот.
AD>Вторым не с чем сравнивать.
Каким вторым? Вы русский язык хорошо понимаете?
Люди, которые видят гай обоих систем, жалуются, что тормозит линуксовый гуй, а не виндовый.
Re[28]: Разработчик ядра Windows NT объяснил причины низкой производительности О
Здравствуйте, eqw, Вы писали:
N>>Нет, тот, кто влез в этот тред с (цитирую) "и получить такой же тормозящй гуй, как в линуксе? Спасибо, не надо." в ответ на замечание про ограничение количества дескрипторов (!) в виндовом GDI. eqw>Я отвечал на сообщение, в котором кто-то, ней разбираясь в истории вопроса, предложил вынести gdi из ring0 дабы решить надуманную проблему.
То есть эксплойты через метафайл или BSOD по хабровской ссылке от деления на -1 приснились не только мне, а и половине участников данного треда, а проблема работы в ring0 кода, который там нахер не нужен — стала надуманной.
N>>Не существует ни на одной из систем, на которых я работал, начиная с, повторюсь, 486/50. eqw>Я очень рад за вас да вот только мотив многочисленных однотипных вопросов на форумах ваш личный опыт выглядит мелковато.
Конечно, по сравнением с отзывами десятков хомячков, которые даже не умеют понять, что они поставили и настроили систему неправильно — он мелковат. OK, тушуюсь и умолкаю.
The God is real, unless declared integer.
Re[22]: Разработчик ядра Windows NT объяснил причины низкой производительности О
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, eqw, Вы писали:
N>>>Нет, тот, кто влез в этот тред с (цитирую) "и получить такой же тормозящй гуй, как в линуксе? Спасибо, не надо." в ответ на замечание про ограничение количества дескрипторов (!) в виндовом GDI. eqw>>Я отвечал на сообщение, в котором кто-то, ней разбираясь в истории вопроса, предложил вынести gdi из ring0 дабы решить надуманную проблему.
N>То есть эксплойты через метафайл или BSOD по хабровской ссылке от деления на -1 приснились не только мне, а и половине участников данного треда, а проблема работы в ring0 кода, который там нахер не нужен — стала надуманной.
Надуманой является проблема 16к дескрипторов, которая была упомянута в оригинальном сообщении.
Эксплоиты к тормозам гуи не имеют отношения.
N>>>Не существует ни на одной из систем, на которых я работал, начиная с, повторюсь, 486/50. eqw>>Я очень рад за вас да вот только мотив многочисленных однотипных вопросов на форумах ваш личный опыт выглядит мелковато.
N>Конечно, по сравнением с отзывами десятков хомячков, которые даже не умеют понять, что они поставили и настроили систему неправильно — он мелковат. OK, тушуюсь и умолкаю.
Ну наконец-то. Осталось признать, что хомяков существенно больше десятка и будет совсем хорошо.
Re[30]: Разработчик ядра Windows NT объяснил причины низкой производительности О
Здравствуйте, eqw, Вы писали:
N>>Конечно, по сравнением с отзывами десятков хомячков, которые даже не умеют понять, что они поставили и настроили систему неправильно — он мелковат. OK, тушуюсь и умолкаю. eqw>Ну наконец-то. Осталось признать, что хомяков существенно больше десятка и будет совсем хорошо.
Накидай, пожалуйста, ссылок на хомяков.
Re[31]: Разработчик ядра Windows NT объяснил причины низкой производительности О
Здравствуйте, MTD, Вы писали:
MTD>Здравствуйте, eqw, Вы писали:
N>>>Конечно, по сравнением с отзывами десятков хомячков, которые даже не умеют понять, что они поставили и настроили систему неправильно — он мелковат. OK, тушуюсь и умолкаю. eqw>>Ну наконец-то. Осталось признать, что хомяков существенно больше десятка и будет совсем хорошо.
MTD>Накидай, пожалуйста, ссылок на хомяков.
Вас в гугле забанили? Запрос я уже давал, но вы предпочли заявить, что вам лень искать. Специально для вас копипастить ссылки из выдачи гугла я не буду.
Re[32]: Разработчик ядра Windows NT объяснил причины низкой производительности О
Здравствуйте, eqw, Вы писали:
MTD>>Накидай, пожалуйста, ссылок на хомяков. eqw>Вас в гугле забанили? Запрос я уже давал, но вы предпочли заявить, что вам лень искать. Специально для вас копипастить ссылки из выдачи гугла я не буду.
У нас выдача может быть разная. В моей выдаче было три таких вопроса, на которые отвечали, типа о чем ты говоришь, все ок. Так, что кинь будь добр ссылок.
Re[33]: Разработчик ядра Windows NT объяснил причины низкой производительности О
Здравствуйте, MTD, Вы писали:
MTD>Здравствуйте, eqw, Вы писали:
MTD>>>Накидай, пожалуйста, ссылок на хомяков. eqw>>Вас в гугле забанили? Запрос я уже давал, но вы предпочли заявить, что вам лень искать. Специально для вас копипастить ссылки из выдачи гугла я не буду.
MTD>У нас выдача может быть разная. В моей выдаче было три таких вопроса, на которые отвечали, типа о чем ты говоришь, все ок. Так, что кинь будь добр ссылок.
Читайте http://linuxfonts.narod.ru/why.linux.is.not.ready.for.the.desktop.current.html#xorg
Re[34]: Разработчик ядра Windows NT объяснил причины низкой производительности О
MTD>I want to make one thing crystal clear — Windows, in some regards, is even worse than Linux and it's definitely not ready for the desktop either.
Удобный подход: найти в статье во списком проблем линукса на десктопе, а особенно проблем исков во списком багов про тормозящий гуй, это замечание и радостно его сюда копипастить. Идите уже обратно на хабр, что ли