LINUX.ORG.RU
ФорумTalks

[wayland mode] линупс - кривое тормозное поделие


0

3

Пока all обсуждают что лучше - wayland или legacy под названием иксы, я бы предложил поднять другую гораздо более интересную тему: ведро линупса есть окаменевший кал мамонта. Его надо перепилить

И вот почему:

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

В реальной жизни не нужно уметь mapнуть любой адрес в любой адрес. Нужно мапать сразу блобы, и в 99% случаев некритично, сколько адресного пространства потеряется из-за выравнивания. У вас много на десктопе программ, у которых по данным top виртуальной памяти по 2гига и более? А гиг? А 512 метров? я окромя ожиревших иксов и фурфокса не упомню, и то - у последнего память занимает heap, которому тоже некритично где лежать, главное лежать. а иксы... :) ну да, иксы. зачем они, когда есть wayland И современные процы позволяют это сделать. Пусть процесс содержит таблицы страниц для верхнего уровня(или среднего для x86-64) , а блобы в памяти содержат нижний уровень. Да, тогда их мапить получится лишь по адресам, кратным 4мб или 2мб. Зато форк и mmap будет мгновенным - не надо создавать на форке кучу структурок, нужных для того, чтоб следить, а кто это юзает физическую страницу, которую мы выгоняем на диск.

Мапнуть блоб к себе? Не вопрос,

memcpy(mytables+offset, blob->phys_addr_tables, sizeof(pagedescr)*((size_of_blob+big_page_size-1)/big_page_size)

Надоела страница? Не вопрос,

pagedescr * tmp=pages[index].where_is_it->phys_addr_tables;
tmp[pages[index].offset]=0;

И все действия такой же сложности примерно. Хелловордовой.

Далее, большинство библиотек и, ширше говоря, тулкитов, идет «паровозом». То есть Qt = {libQtCore + libQtGui + libQtXml + libQtNetwork + blablabla} Вот что мешает возложить на линкер боевую задачу - знать из конфига, какие либлиотеки меж собой дружат, и для каждой такой группы держать один блоб to rule them all? Сколько там стартует типовое кедоприложение из-за динамической линковки? 7500 времени? Причем тормозит из-за того, что по мнению ld-linux.so.2 все либлиотеки «разные», он их каждый раз как в первый раз видит, и заново создает .got для них. ну слинкуй ты их намертво в блоб и держи 1 .got на всех, тем более что он меньше будет, чем раздельный. А поскольку без запроса блоб в память не подкачивается, не потребуется городить какую-то модульность. Не нравится libFoo5 из libFoo[1-100]? Не обращайся, делов-то.

Реализация плевая, соотвествующий код сокращается до предела, но ведь мы же не можем ничего менять потомучтосовместимость. Поэтому проще заменить линупс.

2)Терминалы - зачем это в ведре? От ведра требуется лишь «передать строку» и послать сигнал. Мне казалось, ведро уже умеет это делать. Вот честно, скажите, какая повседневная программа из консоли требует себе в stdin/stdout терминал? НЯП все нормально шуруют через пайп. От пайпа терминал отличается разве что очень полезными ioctlами, без которых жизни красноглазому нет: это установить сколько бит в байте, установить скорость в битах/секунду, и прочая лабуда. Из нового есть только костыль включить/выключить утф8. Я еще понимаю, когда речь о com-портах идет. Ну оставьте эту байду в драйвере ком-порта, зачем это в tty тащить, да еще в ведро? Вынести все в libtty.so и не держать в ведре страшное legacy. Правильно Alan Cox ушел, сколько можно подпирать костылями кучу дерьма, созданную для эмуляции ламповых печатных машинок? Размер «окна», управляющие символы - все это должно делаться в userspace. Один хрен никто в чистом терминале с моргающим курсором давно не сидит. Везде xterm, gnome-terminal, konsole и т.д. и т.п. В винде под цигвином вся эта консольная лабуда работает, хотя там в ведре никаких юниксовых терминалов нет.

3)Планировщик - вот скажите мне пожалуйста, как через nice сделать так, чтоб фоновое приложение икс и его потомки в сумме жрали не меньше 18.2% процессора, но не вытесняли остальных? Задача элементарнейшая - скажите студенту: сделай мне алгоритм, который будет делать кольцевой список задач, у которых может быть такой же список подзадач, и % минимального использования проца в секунду или min((1-reserved_time)/nprocs) если не указано, получишь зачет. Студент сделает. И этот алгоритм будет работать потому что он тупой как хелловорд. Без всяких там cfs/bfs и 12309. Почему у линупса до сих пор такой сраный планировщик, что его можно разбомбить форк-бомбой и на нем под нагрузкой звук хрюкает?

☆☆☆

Ответ на: комментарий от GateKeeper

технически ведро могло бы работать еще в лине, но его перекрывает 99% iowait. и, положа руку на печень, могу сказать, что это broken by design.

ckotinko ☆☆☆
() автор топика
Ответ на: комментарий от GateKeeper

а я уже много лет на ванили. ЕМНИП исправилось ещё в 2.29.

У меня баг проявлялся в лютых фризах иксов, если что-то копировать (причём неважно что, хоть флешку по USB1. Важно что локально, и долго. Баг не сразу проявлялся, а через минуту-другую, и почему-то не проявлялся по сети. Даже если качать на туже флешку, причём быстро)

drBatty ★★
()
Ответ на: комментарий от drBatty

С тех пор, как у меня стабильно не менее 4 ядер на рабочей тачке, фризов не наблюдаю. Осталось только досадное недоразумение в виде локальной полки на графике загрузки процессора в момент IO. Хотя не буду утверждать, что, будь у меня 1 или даже 2 ядра, их (фризов) бы не было. А еще есть подозрение, что VM IO не параллелится между ядрами процессора, таким образом распихивать данные по разным винтам (как минимум в пределах одного контроллера) нет смысла, и скорость чтения с двух винтов параллельно будет min(list(devices_speeds))

GateKeeper ★★
()
Ответ на: комментарий от Deleted

make -j64 считается за нагрузку?

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

segfault ★★★★★
()
Ответ на: комментарий от GateKeeper

не знаю. У меня вообще одно физическое ядро (правда с HT), но никаких фризов я не замечаю.

drBatty ★★
()
Ответ на: комментарий от segfault

даже альсовский dmix икал

«даже»? Dmix это часть библиотеки, загруженной в адресное пространство плеера. Вытеснить плеер - и звука не будет.

AptGet ★★★
()
Ответ на: комментарий от AptGet

Тем не менее, тому же make -j64 это оказалось не по силам.

segfault ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.