The OpenNET Project / Index page

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



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

Оглавление

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

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


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
Добавить, Поддержать, Вебмастеру