The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Осеннее обновление ALT p9 starterkits, opennews (??), 16-Сен-20, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


22. "Осеннее обновление ALT p9 starterkits"  –1 +/
Сообщение от Аноним (22), 16-Сен-20, 16:28 
Я надеюсь, ты понимаешь что 32 бита на 64 битном процессоре неэффективны? Какой-то смысл может быть только на 1 гигабайте ОЗУ или устройствах того же периода, когда это было очень много. Если они не закапывают, они распыляют свои ресурсы впустую (причём, распыление это может быть очень значительным, и в будущем всё станет только хуже). Без системд на сегодня придётся во многом себе отказывать. А от udev и logind так и вовсе отказаться не выйдет (оно конечно можно, но нет). Сопровождение нескольких вариантов будет очень ресурсоёмким, обычно пользователю самому предлагают заботиться обо всём (если авторы не заботятся).
Ответить | Правка | Наверх | Cообщить модератору

33. "Осеннее обновление ALT p9 starterkits"  +/
Сообщение от Аноним (33), 16-Сен-20, 17:30 
Ты видимо не в курсе, что есть "архитектура" x32, которая показывает более высокую производительность на процессорах с 64-битной адресацией памяти. Процессоры x86-й архитектуры 32-битные. Без системд прекрасно живется, особенно с рабочими столами. Кроме того из системды выдрали с мясом elogind - загрузочную часть, и она уже применяется в Gentoo, Void других дистрибутивах.
Ответить | Правка | Наверх | Cообщить модератору

35. "Осеннее обновление ALT p9 starterkits"  +/
Сообщение от Аноним (22), 16-Сен-20, 17:46 
Только это 64 битная архитектура с 32 битными указателями в юзерспейсе, а так да. Никто ассемблер переписывать что-то не побежал, а без него в софте одни тормоза. 32 битных x86 за последние 15 лет выпустили только пару недоатомов, если мне не изменяет память. Распыляться ради очень богатых людей с 20-летним железом? Зачем? Если есть деньги на электричество, они вполне могут на нём сэкономить и купить новое аналогичной производительности. А все ресурсы кинуть на поддержку нормальных пользователей.

Что касается системд, поддержка конфигураций без него всё хуже и хуже, а куски выдранного кода всё глючнее и глючнее. Я знаю, о чём говорю, у меня на части машин openrc (не рекомендую). Вот на дистрибутивы с s6 было бы интересно посмотреть, только от systemd всё равно никуда не денешься.

Ответить | Правка | Наверх | Cообщить модератору

39. "Осеннее обновление ALT p9 starterkits"  +1 +/
Сообщение от YetAnotherOnanym (ok), 16-Сен-20, 18:06 
> пару недоатомов

Внезапно, мир персоналок - это далеко не единственная область, где используются процессоры, включая x86.

Ответить | Правка | Наверх | Cообщить модератору

41. "Осеннее обновление ALT p9 starterkits"  +/
Сообщение от Michael Shigorinemail (ok), 16-Сен-20, 18:10 
С x32 мы поэкспериментировали, но общий вывод -- "не полетело".

Есть ещё виртуалки и контейнеры, и вот там N окружений по K указателей уже может начать и сказываться вовсю.

Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

47. "Осеннее обновление ALT p9 starterkits"  +1 +/
Сообщение от Аноним (22), 16-Сен-20, 18:31 
А вот uksm норм, вы там не собираетесь внедрять? Вот уж где реальная экономия, недостатков не нашёл.
Ответить | Правка | Наверх | Cообщить модератору

53. "Осеннее обновление ALT p9 starterkits"  –1 +/
Сообщение от Michael Shigorinemail (ok), 16-Сен-20, 18:41 
> А вот uksm норм, вы там не собираетесь внедрять?
> Вот уж где реальная экономия, недостатков не нашёл.

Это хорошо бы shaba@ спросить, ну и гляньте упомянутый RC сервера виртуализации -- вдруг там уже всё есть.  Он, кстати, из стартеркита вырос, когда нашёлся заинтересованный человек и занялся вплотную.

Ответить | Правка | Наверх | Cообщить модератору

97. "Осеннее обновление ALT p9 starterkits"  +/
Сообщение от ryoken (ok), 17-Сен-20, 08:47 
x32 уже повыкидывали много где, а где-то даже не приделывали сразу.
Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

94. "Осеннее обновление ALT p9 starterkits"  –1 +/
Сообщение от Аноним (94), 17-Сен-20, 07:25 
> Я надеюсь, ты понимаешь что 32 бита на 64 битном процессоре неэффективны?

Здоровые люди рассматривают частные случаи, процессоров в вакууме в работе не бывает.
> Какой-то смысл может быть только на 1 гигабайте ОЗУ или устройствах
> того же периода, когда это было очень много.

Более того скажу, бывают и по 4Гб ОЗУ, и более с 32 битными процессорами
> Если они не закапывают, они распыляют свои ресурсы впустую

Это уже заезженная мантра всяких троллей и просто необременённых интеллектом людей, которые на это ведутся.
> (причём, распыление это может быть очень значительным, и в будущем всё станет только хуже).

Ох уж эти прогнозисты-вангователи.
> Без системд на сегодня придётся во многом себе отказывать.

1) у Альта есть варианты с systemd, которые мейнстримовые, а есть варианты с инитами здоровых людей.
> А от udev и logind так и вовсе отказаться не выйдет (оно конечно можно, но нет).

Да? Интересно же как подобные проекты живут? Альт, antiX, Artix, гента и гентупроизводные, Void, Alpine?!
> Сопровождение нескольких вариантов будет очень ресурсоёмким,

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

Я вам страшную тайну открою: это везде так!

Итого: Аноним написал какой-то бред, чем заставил "краснеть" других Анонов.

Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

95. "Осеннее обновление ALT p9 starterkits"  +/
Сообщение от Аноним (22), 17-Сен-20, 08:37 
По-моему, какой-то бред нездорового человека написал тут ты. Судя по твоим славам, ничего из перечисленного ты не использовал, зато всегда рад оправдать личный аутизм на тему 32 бит (в своих же глазах, не более).
Ответить | Правка | Наверх | Cообщить модератору

99. "Осеннее обновление ALT p9 starterkits"  –1 +/
Сообщение от Аноним (99), 17-Сен-20, 09:07 
> По-моему, какой-то бред нездорового человека написал тут ты. Судя по твоим славам,
> ничего из перечисленного ты не использовал, зато всегда рад оправдать личный
> аутизм на тему 32 бит (в своих же глазах, не более).

Этот ответ, это такой отзеркаленный ответ в стиле совсем уж детского:  "НЕТ ТЫ!"

Я очень рад, что подтвердилась моя догадка о том, что данный Аноним просто какой-то очередной эксперд от опеннета, который лишь голословно вбрасывает, и явно переносит свои психические опыты на других.

Ответить | Правка | Наверх | Cообщить модератору

100. "Осеннее обновление ALT p9 starterkits"  +/
Сообщение от Аноним (22), 17-Сен-20, 09:14 
Чувак, у тебя ошибки мышления, какие тут могут быть догадки у человека с ошибками мышления?
Ответить | Правка | Наверх | Cообщить модератору

108. "Осеннее обновление ALT p9 starterkits"  –1 +/
Сообщение от Аноним (108), 17-Сен-20, 11:26 
> Чувак, у тебя ошибки мышления, какие тут могут быть догадки у человека
> с ошибками мышления?

О, очередной "есть два мнения, одно моё, а на остальные неправильные" товарищ. Не обольщайтесь, вы тут такой не один и далеко не эксклюзивный.

Ответить | Правка | Наверх | Cообщить модератору

121. "Осеннее обновление ALT p9 starterkits"  +/
Сообщение от Michael Shigorinemail (ok), 17-Сен-20, 16:58 
> Более того скажу, бывают и по 4Гб ОЗУ, и более
> с 32 битными процессорами

Не надо такое применять, если есть хоть какие-то варианты.  Линус, собственно, давно писал не только о том, каким чудовищным костылём является PAE и через какие места оно работает -- но и что 32 бит адресного пространства не хватает уже с гигабайтом памяти на практике; вот перепечатка: http://cl4ssic4l.wordpress.com/2011/05/24/linus-torvalds-abo.../

> Ну это уж разработчикам системы решать, хотят ли они и могут ли
> себе позволить.

А тут да.

Тот же e2k-порт у нас год или два вёлся примерно в треть моих сил, и ничего, за два года дорос до self-hosted (в смысле получилось продолжить его делать уже на машине, целиком и полностью под альтом и загруженной).

Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

157. "Осеннее обновление ALT p9 starterkits"  –1 +/
Сообщение от Webmonkey (?), 18-Сен-20, 15:16 
>но и что 32 бит адресного пространства не хватает уже с гигабайтом памяти на практике

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

Ответить | Правка | Наверх | Cообщить модератору

170. "Осеннее обновление ALT p9 starterkits"  +/
Сообщение от n00by (ok), 18-Сен-20, 17:35 
>>но и что 32 бит адресного пространства не хватает уже с гигабайтом памяти на практике
> Линусу в то еще время предлагали убрать ядро из адресного пространства процесса,
> и патчи присылали, но на это он пойтить никак не мог.

Удалить шлюзы и таблицу страниц?

Ответить | Правка | Наверх | Cообщить модератору

171. "Осеннее обновление ALT p9 starterkits"  +/
Сообщение от Webmonkey (?), 18-Сен-20, 18:20 
Нет лол, это же копейки. Ядро мапится в верхний гиг всех процессов для ускорения сисколов - не нужно сбрасывать кеши. Но есть другой вариант - сделать отдельное адресное пространство для ядра, переключать по сисколу, как обычно. МакосьХ например так была сделана, когда еще была 32х разрядной.

https://lwn.net/Articles/39283/

Ответить | Правка | Наверх | Cообщить модератору

180. "Осеннее обновление ALT p9 starterkits"  +/
Сообщение от n00by (ok), 19-Сен-20, 07:43 
> Нет лол, это же копейки.

Это ядро, которое таким образом останется. Копейки это лишний гигабайт, всего-то +20%, меньше инженерного запаса.


Ответить | Правка | Наверх | Cообщить модератору

186. "Осеннее обновление ALT p9 starterkits"  –1 +/
Сообщение от Webmonkey (?), 19-Сен-20, 12:42 
Линус не от юзерспейса горит, а для ядра памяти будет больше в 4 раза.
Ответить | Правка | Наверх | Cообщить модератору

188. "Осеннее обновление ALT p9 starterkits"  +/
Сообщение от n00by (ok), 19-Сен-20, 13:30 
> для ядра памяти будет больше в
> 4 раза.

Зачем?

Ответить | Правка | Наверх | Cообщить модератору

189. "Осеннее обновление ALT p9 starterkits"  +/
Сообщение от Webmonkey (?), 19-Сен-20, 16:00 
Вы попробуйте почитать, что он там пишет, ссылка выше, Миша запостил. Потому что highmem - костыль,  и ядру нужно больше адресного пространства.

Вот нормальные люди не стали кочевряжится и зделоле:
https://www.freebsd.org/news/status/report-2018-01-2018-09.h...

А царь-линуксу нынче плевать на проблемы 32-холопов.

Ответить | Правка | Наверх | Cообщить модератору

193. "Осеннее обновление ALT p9 starterkits"  +/
Сообщение от n00by (ok), 20-Сен-20, 15:57 
> Вы попробуйте почитать, что он там пишет, ссылка выше, Миша запостил.

Попробую объяснить, что Линус там пишет.

virtual space needs to be bigger than physical space.

Относится не к АП ядра, а к размеру виртуальной памяти.

It needs to be bigger, by a factor of at least two

Коэффициент 2 пригодится, когда одна и та же страница отображается и в ядро, и пространство пользователя.

> Потому
> что highmem - костыль,  и ядру нужно больше адресного пространства.

Я и спрашиваю, зачем нужно. Если бы read() требовала выравнивания адреса буфера по размеру страницы, можно было бы что-то мудрить с отображением дискового кеша и copy-on-write, а так придётся копировать.

Ответить | Правка | Наверх | Cообщить модератору

194. "Осеннее обновление ALT p9 starterkits"  +/
Сообщение от Webmonkey (?), 20-Сен-20, 18:51 
>Относится не к АП ядра, а к размеру виртуальной памяти.

И чем же адресное пространство отличается от размера виртуальной памяти?

>It needs to be bigger, by a factor of at least two
>Коэффициент 2 пригодится, когда одна и та же страница отображается и в ядро, и пространство пользователя.

Это магическое х2 получилось потому что Линус желает линейное отображение физической памяти в виртуальную для ядра и желает иметь ядро (всю ядерную память) замапленным во все процессы.

>Я и спрашиваю, зачем нужно.

А дальше прочитать?

>So you could allocate user pages in it, but you had huge problems with things like internal kernel data structures, which can be the bulk of your memory needs under some (not that unusual) loads. Directory caches, inodes, etc couldn’t use it, and in general it meant that under Linux, if you had more than 4GB of physical memory, you generally ran into problems (since only 25% of memory was available for normal kernel stuff – the rest had to be addressed through small holes in the tiny virtual address space).

Ядерные структуры в highmem не положить, поэтому Линус хочет больше линейно замапленной памяти для ядра.

Ответить | Правка | Наверх | Cообщить модератору

197. "Осеннее обновление ALT p9 starterkits"  +/
Сообщение от n00by (ok), 21-Сен-20, 15:34 
>>Относится не к АП ядра, а к размеру виртуальной памяти.
> И чем же адресное пространство отличается от размера виртуальной памяти?

Уровнем привилегий, с которого разрешён доступ к станицам.

>>It needs to be bigger, by a factor of at least two
>>Коэффициент 2 пригодится, когда одна и та же страница отображается и в ядро, и пространство пользователя.
> Это магическое х2 получилось потому что Линус желает линейное отображение физической памяти
> в виртуальную для ядра и желает иметь ядро (всю ядерную память)
> замапленным во все процессы.

То есть Линус хочет больше памяти и защищённой, и пользовательской -- одновременно (в сумме они и дают всю виртуальную память).  

>>Я и спрашиваю, зачем нужно.
> А дальше прочитать?

Когда человек понимает, он способен объяснить своими словами.

>>So you could allocate user pages in it, but you had huge problems with things like internal kernel data structures, which can be the bulk of your memory needs under some (not that unusual) loads. Directory caches, inodes, etc couldn’t use it, and in general it meant that under Linux, if you had more than 4GB of physical memory, you generally ran into problems (since only 25% of memory was available for normal kernel stuff – the rest had to be addressed through small holes in the tiny virtual address space).
> Ядерные структуры в highmem не положить, поэтому Линус хочет больше линейно замапленной
> памяти для ядра.

Что бы разместить структуры ядра в линейном пространстве, можно, грубо говоря, для их хранения создать фиктивный процесс и использовать его АП ядром. Структуры там будут спокойно лежать. Однако разделять эти структуры с иными процессами затруднительно, как и хранить в них указатели на данные пользователя (представьте, что виртуальные адреса структуры ядра и данных пользователя, на которые ссылаются её поля, пересекаются).

Ответить | Правка | К родителю #194 | Наверх | Cообщить модератору

198. "Осеннее обновление ALT p9 starterkits"  +/
Сообщение от Webmonkey (?), 21-Сен-20, 17:33 
>То есть Линус хочет больше памяти и защищённой, и пользовательской -- одновременно (в сумме они и дают всю виртуальную память).

Необязательно. Ядро можно вовсе не отображать в пользовательские адресные пространства, нет технической необходимости делать так, это оптимизация.

>Что бы разместить структуры ядра в линейном пространстве, можно, грубо говоря, для их хранения создать фиктивный процесс и использовать его АП ядром.

Ага, это и есть схема 4/4. Отдельное АП для ядра. Я уже о ней пишу который раз.

>Структуры там будут спокойно лежать. Однако разделять эти структуры с иными процессами затруднительно,

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

>как и хранить в них указатели на данные пользователя (представьте, что виртуальные адреса структуры ядра и данных пользователя, на которые ссылаются её поля, пересекаются).

Это нормально. Данные в/из буферов пользователя все равно должны проходить через copy_to_user/copy_from_user.

Ответить | Правка | К родителю #197 | Наверх | Cообщить модератору

202. "Осеннее обновление ALT p9 starterkits"  +/
Сообщение от n00by (ok), 22-Сен-20, 08:21 
>>То есть Линус хочет больше памяти и защищённой, и пользовательской -- одновременно (в сумме они и дают всю виртуальную память).
> Необязательно. Ядро можно вовсе не отображать в пользовательские адресные пространства,
> нет технической необходимости делать так, это оптимизация.

Что именно ядро может не отображать? Подумайте о структурах ядра не как об абстракции, а предметно, как о чём-то полезном. Содержимое файлов, например.

>>Что бы разместить структуры ядра в линейном пространстве, можно, грубо говоря, для их хранения создать фиктивный процесс и использовать его АП ядром.
> Ага, это и есть схема 4/4. Отдельное АП для ядра. Я уже
> о ней пишу который раз.

И в который раз Вы так и не ответили, зачем это АП.

>>Структуры там будут спокойно лежать. Однако разделять эти структуры с иными процессами затруднительно,
> Другие процессы и не должны в ядерные структуры лазить
>>как и хранить в них указатели на данные пользователя (представьте, что виртуальные адреса структуры ядра и данных пользователя, на которые ссылаются её поля, пересекаются).
> Это нормально. Данные в/из буферов пользователя все равно должны проходить через copy_to_user/copy_from_user.

Потеря производительности на ровном месте не является нормой, потому и придуман механизм copy-on-write.

Ответить | Правка | К родителю #198 | Наверх | Cообщить модератору

190. "Осеннее обновление ALT p9 starterkits"  +/
Сообщение от Webmonkey (?), 19-Сен-20, 16:46 
и кстати не +20%, а +1/3
Ответить | Правка | К родителю #180 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру