Здравствуйте, eqw, Вы писали:
N>>>>>Несерьёзно. Вынеси видеодрайвер (в версиях начиная с NT4) или драйвер сетевухи, вот тогда можно будет частично приблизиться к понятию микроядра. _>>>>Надо бы сперва gdi вынести из ring0 с его ограничением 16K дескрипторов. eqw>>>и получить такой же тормозящй гуй, как в линуксе? Спасибо, не надо. N>>Ты даже приблизительно не знаешь, где и почему у тебя тормозит гуй, раз пишешь такое. Hint: почитай про Wayland. eqw>У меня он не тормозит, он тормозит у линуксоидов.
Факты в студию. Где тормозит, на чём, какая разница в скорости, при каких условиях.
eqw> И тормозит в том числе потому, что графическая подсистема там сделана «правильно» (овердмзайн иксов) и не засунута в ядро.
Ага, отмазался — этим "в том числе". То есть причины якобы есть, но объяснить их ты не можешь.
eqw>Wayland является убогой попыткой сделать это более эффективно,
Уже сразу и "убогой".
eqw> но находится в зачаточном состоянии и неизвестно когда будет в состоянии заменить иксы
От вопроса, нужен ли собственно GDI (а не видеодрайвер) в ядре, ты благополучно ушёл.
The God is real, unless declared integer.
Re[3]: Разработчик ядра Windows NT объяснил причины низкой производительности ОС
Здравствуйте, Ночной Смотрящий, Вы писали:
MTD>>Увы, уровень аргументации не очень умного человека.
НС>А уж твой то — обозвал дураком и типа все доказал.
В отличии от тебя я так никого не называл, а вежливо попросил объяснить: здесь
Здравствуйте, MTD, Вы писали:
MTD>>>Увы, уровень аргументации не очень умного человека.
НС>>А уж твой то — обозвал дураком и типа все доказал.
MTD>В отличии от тебя я так никого не называл
См. выделенное.
MTD>, а вежливо попросил объяснить: здесь
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, MTD, Вы писали:
MTD>>>>Увы, уровень аргументации не очень умного человека.
НС>>>А уж твой то — обозвал дураком и типа все доказал.
MTD>>В отличии от тебя я так никого не называл
НС>См. выделенное.
Там не конкретно про тебя, а про уровень твоей аргументации.
MTD>>, а вежливо попросил объяснить: здесь
Здравствуйте, MTD, Вы писали:
MTD>Там не конкретно про тебя, а про уровень твоей аргументации.
Ну тогда у тебя "уровень аргументации откровенно тупого человека", так можно сказать? Я ж не про тебя, а про уровень твоей аргументации.
MTD>>>, а вежливо попросил объяснить: здесь
Здравствуйте, netch80, Вы писали:
n> S>1. Procmon или монитор ресурсов, ищем виноватого, убиваем.
n> А он снова запускается, сколько ни убивай. И жрёт 99% CPU, работать невозможно, простейшее действие тормозило на минуты.
В таких случаях помогает принудительное выставление минимального приоритета. Я для этих целей использовал TaskManager Extension, он запоминает какому процессу выставляется какой приоритет.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Ну тогда у тебя "уровень аргументации откровенно тупого человека", так можно сказать? Я ж не про тебя, а про уровень твоей аргументации.
Ну если тебе от этого полегчает — на здоровье!
Re[14]: Разработчик ядра Windows NT объяснил причины низкой производительности О
Здравствуйте, netch80, Вы писали:
N>Представляю, чего тут не представлять. Предположим 1KB блок (сейчас такое редко увидишь, но пусть). 60 миллионов блоков данных — 240 тысяч косвенных блоков (для простоты, уровни дальше последнего не считаем), а в общем случае это 4/1024 == 1/256 от всех занятых блоков, то есть меньше процента — можно их не учитывать. Теперь в таблицах занятости надо поставить признаки свободности всех этих блоков. Предположим, что это всё битовые карты. Тогда они потратят 8000 блоков этих самых карт. Теперь оценим, сколько займут 1) 240000 чтений блоков, 2) 8000 чтений и записей блоков? Даже такое дорогое чтение это пара секунд. Запись свободных — ещё быстрее.
240000 блоков — это 240 мегабайт данных. Современные жесткие диски в принципе способны прочитать 240 метров за две секунды, если данные распологаются последовательно.
Во-первых, такое количество блоков скорее всего разбросаны по диску, так что ни о каких 2 секундах речи быть не может.
Во-вторых, все косвенные блоки — это метаданные, а значит должны пройти через журнал. С этим беда.
N>Я не против экстентов, я против взваливания проблем ext3 на механизм, который не способен их обеспечить. Ещё на UFS1 (FreeBSD) у нас были файлы ну не по 100, но по 10GB. По-Вашему они должны были удаляться около минуты, потому что идёт очень много возни с косвенными блоками? А на практике файл удалялся практически мгновенно (задержка не замечалась человеком). Разумеется, часть затрат сокращалась за счёт более разумного размера блока (8KB по умолчанию), но даже это не сократило бы время менее чем до 10 секунд, если бы Ваши оценки источников затрат были адекватными.
Delete queue. Is active if UFS logging is enabled and consists of inodes that
are unlinked or deleted (v_count equals 1 and i_nlink is less than or equal
to 0). This queue is a performance enhancer for file systems with logging
turned on and observing heavy deletion activity. The delete queue is handled
by the per-file system delete thread, which queues the inodes to be deleted by
the ufs_delete() thread. This significantly boosts response times for
removal of large amounts of data. If logging is not enabled, ufs_delete()
is called immediately. ufs_delete() calls VN_RELE() after it has finished
processing, which causes the inode to once again be processed by ufs_
inactive, which this time puts it on the idle queue. While on the delete
queue, the inode’s i_freef and i_freeb point to the inode itself since the
inodes are not free yet.
It's on Solaris 10 u4. UFS on a single internal disk is used with default mount
options. When deteting about 1000 files (rm -fr *), whose size varies from 10MB
to 2GB in random, and 300GB in total, Solaris takes about 10 to 15 minutes to
complete disk I/O although rm is returned immediately after it's issued. iostat
continuously shows approximately 400 w/s with 7000 kw/s on the UFS affected.
During that period of time, creating and writing new files on that UFS is very
slow. io provider of DTrace shows that it's the sched who is related to the
disk I/O, but DTrace script didn't give the name of the file related to the
I/O. Please help explain why it behaved like that, and how to improve the
performance.
N>Так что болезни ext3 в чём-то другом. Например, в неадекватной работе с журналом или, в общем случае, в чрезмерной грануляции операций.
Как раз в ext3 транзакции группируются в другие транзакции, чтоб было быстрее.
AD>>Тормоза из-за косвенной адресации и фрагментации. N>Первое мы уже разобрали и я с ним не соглашусь. Второе — что Вы имеете в виду под фрагментацией? То, что файл разбросан по диску, или что-то другое?
Да, косвенные блоки и сам файл. Система конечно пытается группировать их, но косвенность подразумевает как минимум пару перемещений головок для доступа к данным. Со временем все становится совсем плохо, если не дефрагментировать.
Re[14]: Разработчик ядра Windows NT объяснил причины низкой производительности О
Здравствуйте, netch80, Вы писали: N>У Вас есть опыт использования NTFS на MIPS машине средней производительности с файлами по 60GB?
причем тут твой MIPS, когда мы говорим про применение ФС на десктопах с IA32 и IA/AMD64? N>Если да — поделитесь. Если нет — Вашим утверждениям и Вашему пафосу цена ноль целых хер десятых.
Цена ноль вашим неуместным выпадам и передергиваниям Можешь сколь угодно придумывать синтетические специфические ситуации, когда ext3 выигрывает NTFS, но в практических юзкейсах, обсуждаемых тут, она конретно сливает
Re[17]: Разработчик ядра Windows NT объяснил причины низкой производительности О
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, eqw, Вы писали:
N>>>>>>Несерьёзно. Вынеси видеодрайвер (в версиях начиная с NT4) или драйвер сетевухи, вот тогда можно будет частично приблизиться к понятию микроядра. _>>>>>Надо бы сперва gdi вынести из ring0 с его ограничением 16K дескрипторов. eqw>>>>и получить такой же тормозящй гуй, как в линуксе? Спасибо, не надо. N>>>Ты даже приблизительно не знаешь, где и почему у тебя тормозит гуй, раз пишешь такое. Hint: почитай про Wayland. eqw>>У меня он не тормозит, он тормозит у линуксоидов.
N>Факты в студию. Где тормозит, на чём, какая разница в скорости, при каких условиях.
Google- [Linux gui is slower than windows]. Запрос весьма популярный, даже в садджеcте есть.
eqw>> И тормозит в том числе потому, что графическая подсистема там сделана «правильно» (овердмзайн иксов) и не засунута в ядро.
N>Ага, отмазался — этим "в том числе". То есть причины якобы есть, но объяснить их ты не можешь.
Причин много и одна из них — кривой дизайн, по которому гуй лежит в юзерспейсе
eqw>>Wayland является убогой попыткой сделать это более эффективно,
N>Уже сразу и "убогой".
Ну а как её ещё назвать? Костыль на костыле.
eqw>> но находится в зачаточном состоянии и неизвестно когда будет в состоянии заменить иксы
N>От вопроса, нужен ли собственно GDI (а не видеодрайвер) в ядре, ты благополучно ушёл.
Вы его мне не задавали.
Re[15]: Разработчик ядра Windows NT объяснил причины низкой производительности О
Здравствуйте, tbasic1, Вы писали:
T>Здравствуйте, netch80, Вы писали: N>>У Вас есть опыт использования NTFS на MIPS машине средней производительности с файлами по 60GB? T>причем тут твой MIPS, когда мы говорим про применение ФС на десктопах с IA32 и IA/AMD64?
Потому что Вы отвечали на реплику, в которой говорилось про скорость на машине с MIPS.
N>>Если да — поделитесь. Если нет — Вашим утверждениям и Вашему пафосу цена ноль целых хер десятых. T>Цена ноль вашим неуместным выпадам и передергиваниям Можешь сколь угодно придумывать синтетические специфические ситуации, когда ext3 выигрывает NTFS, но в практических юзкейсах, обсуждаемых тут, она конретно сливает
Голые слова без единого факта.
The God is real, unless declared integer.
Re[14]: Разработчик ядра Windows NT объяснил причины низкой производительности О
Здравствуйте, fin_81, Вы писали:
_>>Надо бы сперва gdi вынести из ring0 с его ограничением 16K дескрипторов.
_>Дополню про gdi в ядре (ring0)
_>Хабр — Как уронить windows _>http://habrahabr.ru/post/179543/
_>Не проверял, говорят работает
А вот это уже камень в сторону Intel. Потому что генерировать прерывание из *DIV без явного на то запроса — их глупость.
The God is real, unless declared integer.
Re[18]: Разработчик ядра Windows NT объяснил причины низкой производительности О
Здравствуйте, eqw, Вы писали:
N>>>>Ты даже приблизительно не знаешь, где и почему у тебя тормозит гуй, раз пишешь такое. Hint: почитай про Wayland. eqw>>>У меня он не тормозит, он тормозит у линуксоидов.
N>>Факты в студию. Где тормозит, на чём, какая разница в скорости, при каких условиях.
eqw>Google- [Linux gui is slower than windows]. Запрос весьма популярный, даже в садджеcте есть.
Читать выход гугла — как пить из включенного брандспойта — не напьёшься, но весь промокнешь. Ни по одной из ссылок из первых двух экранов я не увидел ни одного внятного объяснения явления, цифр сравнения и разбора причин. Несколько случаев типа "замени старый кривой драйвер на новый", после чего проблема исчезает.
eqw>>> И тормозит в том числе потому, что графическая подсистема там сделана «правильно» (овердмзайн иксов) и не засунута в ядро. N>>Ага, отмазался — этим "в том числе". То есть причины якобы есть, но объяснить их ты не можешь. eqw>Причин много и одна из них — кривой дизайн, по которому гуй лежит в юзерспейсе
Так мы дождёмся объяснения, что именно из гуя "лежит в юзерспейсе" и как это мешает?
eqw>>>Wayland является убогой попыткой сделать это более эффективно, N>>Уже сразу и "убогой". eqw>Ну а как её ещё назвать? Костыль на костыле.
Где именно костыли? Расшифруй.
eqw>>> но находится в зачаточном состоянии и неизвестно когда будет в состоянии заменить иксы N>>От вопроса, нужен ли собственно GDI (а не видеодрайвер) в ядре, ты благополучно ушёл. eqw>Вы его мне не задавали.
Вы отвечали на реплику: "Надо бы сперва gdi вынести из ring0 с его ограничением 16K дескрипторов."
Так что жду ответа на вопрос.
The God is real, unless declared integer.
Re[16]: Разработчик ядра Windows NT объяснил причины низкой производительности О
Здравствуйте, netch80, Вы писали:
N>Потому что Вы отвечали на реплику, в которой говорилось про скорость на машине с MIPS.
я в плоском виде читаю форум, там не видно иерархии.
N>>>Если да — поделитесь. Если нет — Вашим утверждениям и Вашему пафосу цена ноль целых хер десятых. T>>Цена ноль вашим неуместным выпадам и передергиваниям Можешь сколь угодно придумывать синтетические специфические ситуации, когда ext3 выигрывает NTFS, но в практических юзкейсах, обсуждаемых тут, она конретно сливает
N>Голые слова без единого факта.
читайте эту тему, тут приводили факты
Re[15]: Разработчик ядра Windows NT объяснил причины низкой производительности О
Здравствуйте, netch80, Вы писали:
_>>Дополню про gdi в ядре (ring0)
_>>Хабр — Как уронить windows _>>http://habrahabr.ru/post/179543/
_>>Не проверял, говорят работает
N>А вот это уже камень в сторону Intel. Потому что генерировать прерывание из *DIV без явного на то запроса — их глупость.
Глупость — не глупость, но это документированное поведение.
Глупость то, что "ядерные кодеры" используют опасную операцию деления, кидающая исключение "деление на ноль".
Про глупость запихивания функций работающих с шрифтами, графическими метафайлами и другими сложными графическими объектами в ядро я промолчу.
Re[19]: Разработчик ядра Windows NT объяснил причины низкой производительности О
N>Читать выход гугла — как пить из включенного брандспойта — не напьёшься, но весь промокнешь. Ни по одной из ссылок из первых двух экранов я не увидел ни одного внятного объяснения явления
Ну сами ссылки-то вы увидели? Проблема присутствует и является довольно популярной, универсального решения ее не предлагается. Проблемы "почему в windows интерфейс медленнее чем в linux", например, на форумах в том же количествве не наблюдается.
В качестве упражнения попробуйте обьяснить, почему в Linux нет работающего аналога виндового remote desktop (который с приличной же скоростью работает на 56k модемных соединениях) и почему VNC под линуксом работает существенно медленнее, чем под виндами.
>Несколько случаев типа "замени старый кривой драйвер на новый", после чего проблема исчезает.
И еще тонна случаев, когда замена драйвера не помогает и предлагается не сравивать GUI в windows и Linux, потому что они совсем по-разному спроектированы .
N>Так мы дождёмся объяснения, что именно из гуя "лежит в юзерспейсе" и как это мешает?
О боги, как же это скучно. Мне сейчас вам рассказывать очевидные вещи о том, как спроектирован X и как взаимодействуют меду собой X window server и X window client? Какая часть этого взаимодействия идет через юзерспейс? Я не буду этого делать, мне лень. Хотите доказать, что этого не происходит — вперед, доказывайте, будет интересно почитать.
eqw>>>>Wayland является убогой попыткой сделать это более эффективно, N>>>Уже сразу и "убогой". eqw>>Ну а как её ещё назвать? Костыль на костыле. N>Где именно костыли? Расшифруй.
Мне слишком скучно обьяснять очевидные вещи. Если вы про wayland знаете только из википедии и не понимаете, в чем там костыли, что задаете такой вопрос, скучно вдвойне.
N>Вы отвечали на реплику: "Надо бы сперва gdi вынести из ring0 с его ограничением 16K дескрипторов." N>Так что жду ответа на вопрос.
Вы русский язык понимаете? В реплике не было вопроса.
Повторяю еще раз — если вынести GDI из ring0, упадет перформанс GDI и как следствие GUI будет тормозить. Прямо как в линуксе.
Re[15]: Разработчик ядра Windows NT объяснил причины низкой производительности О
Здравствуйте, tbasic1, Вы писали:
T>Здравствуйте, netch80, Вы писали: N>>У Вас есть опыт использования NTFS на MIPS машине средней производительности с файлами по 60GB? T>причем тут твой MIPS, когда мы говорим про применение ФС на десктопах с IA32 и IA/AMD64?
Это Windows привязана к x86 и amd64, а мы говорим о ФС в принципе.
T>Цена ноль вашим неуместным выпадам и передергиваниям Можешь сколь угодно придумывать синтетические специфические ситуации, когда ext3 выигрывает NTFS, но в практических юзкейсах, обсуждаемых тут, она конретно сливает
ext3 — это лишь один из возможных вариантов, тогда как кроме NTFS на win больше ничего и нет.
NTFS опережала многих на момент выхода, но она не была единственной. Почему ext2/ext3 получили такую массовость для меня до сих пор загадка. Возможно, для своих задач они были вполне хороши, а может из-за обратной совместимости, но более быстрые альтернативы были.
.
