The OpenNET Project / Index page

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



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

"Релиз ядра Linux 6.4"  +/
Сообщение от opennews (??), 26-Июн-23, 13:02 
После двух месяцев разработки Линус Торвальдс представил релиз ядра Linux 6.4. Среди наиболее заметных изменений: возможность создания kernel worker из пространства пользователя, продолжение интеграции поддержки языка Rust, поддержка механизма Intel LAM (Linear Address Masking), дедупликация страниц памяти на уровне процессов,  поддержка привычных итераторов в BPF, поддержка перехода в спящий режим для систем RISC-V, возможность трассировки пользовательских процессов, новый механизм управления памятью модулей ядра, запрет отключения SELinux во время работы, поддержка шифрования RPC-пакетов NFS, удаление SLOB slab allocator...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=59344

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

Оглавление

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


2. "Релиз ядра Linux 6.4"  –9 +/
Сообщение от pavlinux (ok), 26-Июн-23, 13:03 
> поддержки дедупликации осуществляется через prctl(PR_SET_MEMORY_MERGE)  для процесса целиком
> и наследуется для дочерних процессов, без необходимости активации для каждого диапазона памяти ...

Товарищ Майор будет рад

> В интерфейсе асинхронного ввода/вывода io_uring появилась возможность одновременной ...

Танцуем танго и нижний брейк, но одновременно :))

> Вместо SLOB следует использовать SLUB или SLAB.

SLAB  уже с фейсбучными патчами?

> В XFS добавлены изменения, необходимые для реализации проверки ФС на лету

Лет через 5 можно будет юзать

>  Реализован универсальный программный интерфейс для управления светодиодными индикаторами на сетевых коммутаторах или сетевых платах.

Ждём видосики: рубимся в Doom на стойке из Cisco .

> В драйвере MediaTek MT76 добавлена поддержка WiFi 7.

Wifi 6 уже все попробовали? :)

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

134. "Релиз ядра Linux 6.4"  +3 +/
Сообщение от Аноним (-), 27-Июн-23, 02:45 
> Товарищ Майор будет рад

А что оно ему дает? Экономию RAM? Это не только майорам нравится. В остальных случаях нельзя ли поподробнее чем это кому грозит?

> Танцуем танго и нижний брейк, но одновременно :))

А был бы у тебя хвост, смог бы и еще чего-нибудь заодно.

> Лет через 5 можно будет юзать

Да юзать то можно хоть сейчас. Но с их управлением девайсами толку с этого...

> Ждём видосики: рубимся в Doom на стойке из Cisco .

Это, типа, из их светодиодиков экран для дума собрать? Типа, как на здании в тетрис светом в комнатах играли? Ох, мсье знает толк...

> Wifi 6 уже все попробовали? :)

Тсс, не мешай ящеркам палиться. И попроси у них нормальные батарейки в следующий раз. И хрен с ним, с гигабитами через подпространство.

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

140. "Релиз ядра Linux 6.4"  +/
Сообщение от iCat (ok), 27-Июн-23, 05:35 
>Товарищ Майор будет рад

Особенно майор Джонс...

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

3. Скрыто модератором  –1 +/
Сообщение от Аноним (3), 26-Июн-23, 13:09 
Ответить | Правка | Наверх | Cообщить модератору

5. Скрыто модератором  +1 +/
Сообщение от Аноним (5), 26-Июн-23, 13:10 
Ответить | Правка | Наверх | Cообщить модератору

6. Скрыто модератором  +1 +/
Сообщение от Аноним (6), 26-Июн-23, 13:14 
Ответить | Правка | Наверх | Cообщить модератору

7. Скрыто модератором  –6 +/
Сообщение от void (??), 26-Июн-23, 13:14 
Ответить | Правка | Наверх | Cообщить модератору

9. Скрыто модератором  –3 +/
Сообщение от Аноним (6), 26-Июн-23, 13:17 
Ответить | Правка | Наверх | Cообщить модератору

21. Скрыто модератором  +1 +/
Сообщение от void (??), 26-Июн-23, 13:35 
Ответить | Правка | Наверх | Cообщить модератору

23. Скрыто модератором  +2 +/
Сообщение от Аноним (23), 26-Июн-23, 13:40 
Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

26. Скрыто модератором  +2 +/
Сообщение от Аноним (5), 26-Июн-23, 13:42 
Ответить | Правка | Наверх | Cообщить модератору

30. Скрыто модератором  +1 +/
Сообщение от void (??), 26-Июн-23, 13:47 
Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

28. Скрыто модератором  +2 +/
Сообщение от Аноним (28), 26-Июн-23, 13:44 
Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

10. "Релиз ядра Linux 6.4"  –1 +/
Сообщение от Аноним (10), 26-Июн-23, 13:17 
>Удалён SLOB (slab allocator), устаревший механизм распределения памяти slab, который был спроектирован для систем с небольшим объёмом памяти.

и чо типерь делать? вот как типерь быть? дальше быть на debian 10.0? а патом куда периходить?

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

24. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (23), 26-Июн-23, 13:41 
а чем тебе 12-тый не устраивает?
Ответить | Правка | Наверх | Cообщить модератору

47. "Релиз ядра Linux 6.4"  +1 +/
Сообщение от Аноним (47), 26-Июн-23, 14:45 
Тем, что он не 12.0.1
Ответить | Правка | Наверх | Cообщить модератору

52. "Релиз ядра Linux 6.4"  +1 +/
Сообщение от Аноним (23), 26-Июн-23, 14:53 
ну тогда страдай

¯\_(%)_/¯

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

46. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (46), 26-Июн-23, 14:43 
SLOB это вообще не для десктопов, а для embedded.
Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

179. Скрыто модератором  +/
Сообщение от Аноним (-), 28-Июн-23, 08:48 
Ответить | Правка | Наверх | Cообщить модератору

13. "Релиз ядра Linux 6.4"  +7 +/
Сообщение от Ананий (?), 26-Июн-23, 13:19 
Мне вот другое интересно с этой дедупликацией памяти.
1)Ну вот отдедуплицировали три блока. Получили 1.
2)Вносим в 2 блока изменение, а памяти на раздупликацию, внезапно нетути.
3)?
Ответить | Правка | Наверх | Cообщить модератору

17. "Релиз ядра Linux 6.4"  +8 +/
Сообщение от Аноним (17), 26-Июн-23, 13:24 
OOM, убиваем что ненужно :-D
Ответить | Правка | Наверх | Cообщить модератору

131. "Релиз ядра Linux 6.4"  +1 +/
Сообщение от пох. (?), 27-Июн-23, 01:07 
> OOM, убиваем что попало!

Все убитое - объявляем ненужно.
поправил, не благодари.

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

142. "Релиз ядра Linux 6.4"  –2 +/
Сообщение от Аноним (-), 27-Июн-23, 06:27 
> Все убитое - объявляем ненужно.
> поправил, не благодари.

При том у тех кто не любит RTFM оно будет убиваться по рандому. Более разумные существа которым так не нравится - прочитают про oom score adjust.

А если кого волновали вон те случаи, в линухе ПО ДЕФОЛТУ врублен OVERCOMMIT. Если кто не знает - он позволяет программам заказывать больше памяти чем реально есть в надежде что они не будут по факту это юзать, при том в большей части это весьма обосновано, достаточно сравнить RSS vs VSZ и сделать выводы о том что в вон том фокусе есть пойнт. Однако всегда возможна ситуация что прога захотела поюзать новую страницу - упс, ее нет, упс, если не ошибаюсь, SIGSEGV. В свете чего не понятно что вон то меняет в дефолтном поведении... кроме того что больше прог удастся запустить.

Если кому это поведение критично - так оно настраивается. И вон то и оверкомит.

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

18. "Релиз ядра Linux 6.4"  +1 +/
Сообщение от anon2 (?), 26-Июн-23, 13:25 
swap
Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

20. "Релиз ядра Linux 6.4"  –4 +/
Сообщение от birdie (ok), 26-Июн-23, 13:34 
SWAP - это худший костыль компьютерной индустрии и он должен умереть.

Впрочем, на моих компах и серверах (> 200, high-load, >100 запросов в секунду) он выключен. Полёт отличный!

В Линукс зачем-то hibernate = swap, но это безумие и, надеюсь, hibernate отделят. Впрочем, и hibernate с приходом SSD/NVMe потерял актуальность.

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

22. "Релиз ядра Linux 6.4"  +17 +/
Сообщение от Аноним (5), 26-Июн-23, 13:40 
Ты просто залил проблему железом. Есть задачи где так просто не сделать. А своп это то что позволяло шевелится 95 шинды на компе с 4 мегами оперы.
Ответить | Правка | Наверх | Cообщить модератору

27. "Релиз ядра Linux 6.4"  –3 +/
Сообщение от Аноним (23), 26-Июн-23, 13:42 
осталось найти такой комп и задачи для 95ой шинды...

а так да...

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

29. "Релиз ядра Linux 6.4"  +1 +/
Сообщение от Аноним (29), 26-Июн-23, 13:45 
Своп это то что сегодня позволяет играть в компьютерные игры с хорошими текстурами и без видеокарты с 16гб видеопамяти. В процессе это незаметно, только подгрузки уровня подольше (иногда очень подольше, но сами уровни не лагают).
Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

98. "Релиз ядра Linux 6.4"  +3 +/
Сообщение от Аноним (98), 26-Июн-23, 19:22 
Он всё правильно написал, своп — это костыль для решения проблемы нехватки ресурсов. Да и всё это разделение на кэш процессора, RAM и диск само по себе убогий костыль, существующий только из-за того, что читать/писать с/на ППЗУ с частотой CPU пока не научились. И эти костыли с нами надолго.
Ответить | Правка | Наверх | Cообщить модератору

106. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (29), 26-Июн-23, 20:17 
Ну смотри, даже в играх требование файла подкачки или отказывается работать, независимо от того сколько у тебя памяти. Разработчики адекватно рассудили, что неиспользуемые ресурсы неплохо бы вытеснить из памяти. На практике своп решает такие вопросы как утечки памяти в видеодрайвере. Ты либо каждый день перезапускаешь систему, либо раз в год с включённым свопом.
Ответить | Правка | Наверх | Cообщить модератору

35. "Релиз ядра Linux 6.4"  –1 +/
Сообщение от Аноним (35), 26-Июн-23, 13:58 
А в мобильниках/embedded он тоже используется? Посмотрим как быстро от него нaкроется NAND/eMMC
Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

39. "Релиз ядра Linux 6.4"  +3 +/
Сообщение от llolik (ok), 26-Июн-23, 14:03 
> А в мобильниках/embedded он тоже используется?

Там zram же используется, вроде как. Что, в принципе, тоже swap, но только в RAM.

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

44. "Релиз ядра Linux 6.4"  +2 +/
Сообщение от Аноним (44), 26-Июн-23, 14:24 
Назначение zram другое. Это не замена свопа
Ответить | Правка | Наверх | Cообщить модератору

62. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (62), 26-Июн-23, 16:07 
зато у свопа поверх zram назначение такое же как и у свопа поверх любого другого блочного устройства
Ответить | Правка | Наверх | Cообщить модератору

145. "Релиз ядра Linux 6.4"  +/
Сообщение от shardddin (?), 27-Июн-23, 06:40 
Я тоже так по началу думал..., а оказалось, что нет - скорее это просто СВОП...
Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

49. "Релиз ядра Linux 6.4"  +2 +/
Сообщение от Анони (?), 26-Июн-23, 14:46 
Так и работают эти ваши мобильники и ембеддед прям скажем так себе.
Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

54. "Релиз ядра Linux 6.4"  –1 +/
Сообщение от Аноним (54), 26-Июн-23, 15:05 
Уж лет 15 SSD используются, а народ всё своп на HDD переносит.
Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

57. "Релиз ядра Linux 6.4"  +1 +/
Сообщение от Аноним (57), 26-Июн-23, 15:29 
SSD за эти 15 лет лучше не стали.
Ответить | Правка | Наверх | Cообщить модератору

63. "Релиз ядра Linux 6.4"  –1 +/
Сообщение от Аноним (5), 26-Июн-23, 16:07 
SSD сейчас сильно лучше чем были 15 лет назад инфа сотел.
Ответить | Правка | Наверх | Cообщить модератору

72. "Релиз ядра Linux 6.4"  +4 +/
Сообщение от Kuromi (ok), 26-Июн-23, 16:25 
Сейчас намного лучше контроллеры и алгоритмы, а вот сама память - хуже.
Ответить | Правка | Наверх | Cообщить модератору

135. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (-), 27-Июн-23, 02:48 
> SSD сейчас сильно лучше чем были 15 лет назад инфа сотел.

Особенно дешевые TLC - так что на весь интернет стоит вой от разваленных файлух, когда оно чото протирается - и довольно быстро :)

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

205. "Релиз ядра Linux 6.4"  +/
Сообщение от по (?), 03-Июл-23, 17:35 
купил на али 1тб за 2к руб, тупо под торренты, чтобы винты не шуршали, сдохнет да и пофиг, перекачаю, если у людей мозгов нет и они хранят ценные данные на дешевых носителях так кто теперь виноват?
Ответить | Правка | Наверх | Cообщить модератору

79. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (79), 26-Июн-23, 16:35 
Пользуюсь Samsung 850 Pro на 240 гигов более 7 лет, не отключав "подкачку", "профили браузера" и прочую чушь что советовали когда то давно. Чего я с ним только не делал, и оффтопик стоял, и линь поднимал, некоторые игры на нём держал что бы быстрее запускать. Работает замечательно и по сей момент
Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

80. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (29), 26-Июн-23, 16:43 
А сколько запись? У меня и без свопа 200+ гигабайт за день в норме (и они понятное дело пишутся в одни и те же 100 мегабайт). Я слышал, Самсунги очень быстро дохнут под нагрузкой, своп это не та нагрузка всё же. И проблема Самсунгов, что не угадаешь, какой нормальный, а какой мусорный. А какой вообще сдохнет просто так.
Ответить | Правка | Наверх | Cообщить модератору

82. "Релиз ядра Linux 6.4"  +/
Сообщение от xrensgory (ok), 26-Июн-23, 17:02 
у меня какой-то интел на 40гигов. даже не полмню с каким типом памяти.
Соответственно свопа у меня 40 гигов. 10 лет полет нормальнрый. До этого года три работал системным.
Ответить | Правка | К родителю #79 | Наверх | Cообщить модератору

88. "Релиз ядра Linux 6.4"  +/
Сообщение от n00by (ok), 26-Июн-23, 17:57 
Это называется "систематическая ошибка выжившего".
Ответить | Правка | Наверх | Cообщить модератору

107. "Релиз ядра Linux 6.4"  +/
Сообщение от МестныйЭксперт (?), 26-Июн-23, 20:26 
Возможно, но меня устраивает
Ответить | Правка | Наверх | Cообщить модератору

113. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (113), 26-Июн-23, 21:43 
Может действительно повезло, а может просто свап пишется равномерно и износ всего диска тоже идет равномерно. А если умрет - то и не жалко.
Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

120. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (54), 26-Июн-23, 22:38 
Контроллер SSD всё пишет равномерно. Своп там, кэш браузера или блюрей с порнухой — ему наплевать. А по сравнению со всем остальным количеством записей в своп можно пренебречь: это во времена вышеупомянутой Win95 с 4 МБ своп использовался действительно активно, а сейчас нет особой проблемы использовать количество оперативки, необходимое для наших задач.
Ответить | Правка | Наверх | Cообщить модератору

211. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (-), 09-Июл-23, 22:07 
> Контроллер SSD всё пишет равномерно. Своп там, кэш браузера или блюрей с
> порнухой — ему наплевать.

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

> А по сравнению со всем остальным количеством записей
> в своп можно пренебречь: это во времена вышеупомянутой Win95 с 4
> МБ своп использовался действительно активно, а сейчас нет особой проблемы использовать
> количество оперативки, необходимое для наших задач.

Все это зависит от характера задач. И если какая-то пакость уйдет вразнос, дырка в SSD образуется довольно быстро. ZRAM выгодно отличается от этого отсутствием лимита на циклы записи, так что даже если всеми забытый комп будет весь день свопиться в ZRAM - да и похрен. А если на SSD... эм...

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

136. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (-), 27-Июн-23, 02:49 
> Это называется "систематическая ошибка выжившего".

Просто те которые на 40 гиг могли быть с 2-level cell достаточно неубиваемым, а своп не сильно активно юзался. И все же не очень понятно зачем эмутировать оперативку достаточно тормозным способом. Ну ладно там ZRAM если поставить больше оперативы ну совсем не вариант.

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

143. "Релиз ядра Linux 6.4"  +/
Сообщение от n00by (ok), 27-Июн-23, 06:34 
Просто например у меня с 2010 года в одном массиве стояло две Тошибы на 60 гиг, и только одна выжила. :)
Ответить | Правка | Наверх | Cообщить модератору

180. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (180), 28-Июн-23, 09:01 
> Просто например у меня с 2010 года в одном массиве стояло две
> Тошибы на 60 гиг, и только одна выжила. :)

Wearout флеша - вероятностный процесс. Блок может стать плохим на 10-м цикле. Или на 10 000-м. Распределение, вероятно, нечто типа bath curve обычного в таких делах.

И два чипа флеша, даже взятые с одной вафли - вовсе не обязательно идентичны по свойствам, есть достаточно нехилый разброс. По этой причине после того как чипы напекли делается дофига валидации, классификации, тестов и проч.

Простой пример: у NAND прямо с фабрики в чипе defect list - и чип считается исправным, если в нем СРАЗУ С ФАБЫ "не более чем эн дефектов". SSD использует меньше полезной емкости чем суммарная емкость чипов, часть блоков зарезервирована на замену тех которые стали сбоить. Ну а как этот резерв заканчивается, фирмвара SSD и оказывается в патовой ситуации, как максимум в readonly выпадает. Потому что заменять дефектные блоки более не на что. Если теорвер так сложился что резерв быстро вылетел - ну, не повезло.

А если хочется эту механику познать более плотно - есть такая штука как ubi и ubifs, кладется на вот именно такой RAW NAND (для чего конечно же железка с RAW NAND нужна, типа одноплатника, современного роутера, etc) - и там все эти параметры можно от души покрутить самому, по вкусу. Можно поменьше емкость, побольше блоков на резерв, или наоборот. Стоит сказать что вон то несколько канительно т.к. надо оперировать странными вещами, типа размера Erase Block и "page" флеша, часть page отведена под FEC, часть eraseblock - под служебные маркеры, и математика получается не очень круглая даже на SLC/2-level MLC. А у 3-level cell еще и параметры бывают странноватые, потому что 3 бита на ячейку не очень круглое число.

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

184. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (54), 28-Июн-23, 11:47 
> Простой пример: у NAND прямо с фабрики в чипе defect list - и чип считается исправным, если в нем СРАЗУ С ФАБЫ "не более чем эн дефектов". SSD использует меньше полезной емкости чем суммарная емкость чипов, часть блоков зарезервирована на замену тех которые стали сбоить. Ну а как этот резерв заканчивается, фирмвара SSD и оказывается в патовой ситуации, как максимум в readonly выпадает. Потому что заменять дефектные блоки более не на что. Если теорвер так сложился что резерв быстро вылетел - ну, не повезло.

Прямо как у HDD, надо заметить.

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

199. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (199), 01-Июл-23, 13:28 
HDD отказывают как bath curve - но это немного отличатеся от флеша, в том смысле что у них нет отказов секторов за факт эн перезаписей. Магнитному слою пофиг 5 раз его переписали или 50 000, это не есть фактор для отказа. А у флеша вот именно циклы - разбалтывают электрические параметры ячейки и в конце концов перестает правильно уровни отличать.
Ответить | Правка | К родителю #184 | Наверх | Cообщить модератору

206. "Релиз ядра Linux 6.4"  +/
Сообщение от voiceofreason (?), 05-Июл-23, 15:26 
Если систематическая, может и не ошибка вовсе?
Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

207. "Релиз ядра Linux 6.4"  +/
Сообщение от n00by (ok), 05-Июл-23, 16:40 
У Вас есть шанс получить Нобелевскую премию по математике.
Ответить | Правка | Наверх | Cообщить модератору

174. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (174), 28-Июн-23, 03:33 
Не помню с каким ...SLC, ага.
Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

104. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (104), 26-Июн-23, 19:54 
Про 15 лет загнул конечно. Период в 8-10 лет более реалистичный.
Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

112. "Релиз ядра Linux 6.4"  +1 +/
Сообщение от Аноним (54), 26-Июн-23, 21:20 
10 лет массово, а 8 — уже очень массово. А так, если у кого были лишние 500$, тот и в 2008-2009 мог 128 Гб взять под систему и софт.
Ответить | Правка | Наверх | Cообщить модератору

43. "Релиз ядра Linux 6.4"  +2 +/
Сообщение от Аноним (44), 26-Июн-23, 14:23 
WMware WS хрен запустится без наличия своп-раздела.
Но у тебя все хорошо
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

53. "Релиз ядра Linux 6.4"  +1 +/
Сообщение от Аноним (54), 26-Июн-23, 14:55 
Hibernate это вообще не про скорость загрузки.
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

56. "Релиз ядра Linux 6.4"  +2 +/
Сообщение от User (??), 26-Июн-23, 15:26 
Так давно уже отдельный раздел не нужен, можно в файл сбрасывать... ну, иногда. На некоторых дистрибутивах. На некоторые файловые системы. С некоторой комбинацией запущенного софта и установленного железа. С определенной вероятностью может даже сработать - у некоторых даже несколько раз подряд, но тут сам не видел и врать не буду.
В общем и правда - проще сказать, что "hibernate потерял актуальность".
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

58. "Релиз ядра Linux 6.4"  +1 +/
Сообщение от Аноним (58), 26-Июн-23, 15:44 
Чото хайлоуд обмельчал каеш, кхем кхем, безусловно колличество запросов не мерило их ценности, но больше ста запросов в сек разве что для каких то супер задач хайлоуд, даж для фин транзакций нихуайлоуд
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

95. "Релиз ядра Linux 6.4"  +2 +/
Сообщение от Легивон (?), 26-Июн-23, 18:57 
Тебе 15 лет, да? Или откуда такой идеализм?
Допустим у тебя есть нагруженый кластер Ceph на 10 стоек. Пару стоек моргнуло и запустилось снова. Начался resync, который жрет тучу памяти. Что по твоему лучше? Потормозить но синхронизоваться? Или лавинообразно сдохнуть от ООМ?
Такой вариант развития событий с памятью был в инциденте с Ceph у DO. Печально известный "мы старались, но у нас не получилось, проект закрыт" Cloudmouse, тоже сдох из-за недостатка памяти. Но там (для честности) помимо прочего еще и неадекватность присутствовала.
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

99. "Релиз ядра Linux 6.4"  –1 +/
Сообщение от Аноним (98), 26-Июн-23, 19:26 
> Что по твоему лучше?

По-моему надо было лучше планировать, вовремя закупать оборудование, настраивать OOM score, и другие кошерные вещи. Но если из вариантов только тормозить или умереть… Лучше умереть. Быстрее деньги на оборудование найдутся.

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

105. "Релиз ядра Linux 6.4"  +2 +/
Сообщение от Аноним (104), 26-Июн-23, 20:02 
Твой подход не верный.

Для примера реальный случай. Рендер в Blender на домашнем компьютере, который никогда для этого не использовался, да и был собран для другого. Память при рендере ушла в ноль, а далее был задействован swap. Работа выполнена, хоть и медленно. Раз в год и палка стреляет)

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

129. "Релиз ядра Linux 6.4"  +/
Сообщение от Вася (??), 27-Июн-23, 00:20 
на десктопе очень неплохо работает zram. Тем более с нынешними процессорами и объемами памяти, когда тупо всякое ненужное у тебя пережимается и практически забываешь, что бывает oom
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

157. "Релиз ядра Linux 6.4"  +/
Сообщение от Tron is Whistling (?), 27-Июн-23, 09:20 
Чо, >200 запросов в секунду - это уже у наших любителей локалхоста highload?
У меня пых >1000 запросов в секунду на маленькой виртуалке делает.
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

25. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (29), 26-Июн-23, 13:41 
Кстати, uksm годная штука, рекомендую. Особенно заметно на жава аппликухах, которые в ~2 раза меньше жрут. Процессора обычно достаточно, а вот без кешей хуже живётся.
Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

59. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (58), 26-Июн-23, 15:46 
для ksm над готовить всякие костыли вроде LD_PRELOAD оберток и прочего, изкаропки ток хипервизоры поддерживают
Ответить | Правка | Наверх | Cообщить модератору

66. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (29), 26-Июн-23, 16:11 
Uksm просто работает, периодически мержит одинаковые страницы фоном.
Ответить | Правка | Наверх | Cообщить модератору

123. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (123), 26-Июн-23, 23:36 
UKSM уже никем довольно давно не поддерживается. Давно столкнулись с архитектурными проблемами, патч вызывал проблемы со стабильностью и с эффективностью тоже были вопросы.
Ответить | Правка | Наверх | Cообщить модератору

128. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (29), 27-Июн-23, 00:07 
Какие проблемы со стабильностью и эффективностью, например? Я где-то пару лет использовал повсюду где можно. Патч можно и самому обновлять под апдейты (на гитхабе только под необновлённые ядра).
Ответить | Правка | Наверх | Cообщить модератору

34. "Релиз ядра Linux 6.4"  +2 +/
Сообщение от Аноним (34), 26-Июн-23, 13:54 
ну это примерно как с аллокатором: он тебе указатель таки отдаст, но память будет выделяться только когда попытаешься записать туда что-нить (и тут может быть ООМ)
Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

161. "Релиз ядра Linux 6.4"  +/
Сообщение от Anon3 (?), 27-Июн-23, 11:52 
Т.е. даже сейчас любой код, меняющий значение ячейки памяти (например X=5+3), может дать исключение ООМ? Это вообще в языках программирования нормально реализовано?
Ответить | Правка | Наверх | Cообщить модератору

178. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (178), 28-Июн-23, 08:45 
1) X=5+3 современный компилер скорее всего оформит как нечто типа mov r1, #8, посчитав еще в компилтайме.
2) При этом обращения в память скорее всего не будет вообще.
3) Если X далее не используется или это ни на что не влияет, то этого кода не будет вообще.
4) Если это было про возможность что array[10005000] = 10 упадет, вот тут уже возможны варианты. По дефолту в линухе оверкомит, а страницы памяти физически выделяются только когда начинают их реально использовать. И можно номинально заказать себе сильно больше формальной аллокации чем реально система могла обеспечить. Это не ведет к проблемам пока вы это все и сразу юзать не удумаете. Это отключаемо если так не нравится, это гарантирует семантику вещей типа malloc()  yj неэффективно по использованию RAM.
Ответить | Правка | Наверх | Cообщить модератору

38. "Релиз ядра Linux 6.4"  –1 +/
Сообщение от pavlinux (ok), 26-Июн-23, 14:01 
>  3)?

Отдуплившаяся страница помечается как CoW, как кто-то полезет
в неё на ЗАПИСЬ, она раздупляется и становиться  самостоятельной.

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

60. "Релиз ядра Linux 6.4"  +1 +/
Сообщение от Тот_ещё_аноним (ok), 26-Июн-23, 15:46 
>> 3)?

Тоже самое, что и без дедупликации
Но сильно позже и с меньшими шансами, ибо память сэкономлена

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

67. "Релиз ядра Linux 6.4"  +1 +/
Сообщение от Мамкинтролль (?), 26-Июн-23, 16:11 
Корректнее так:
1) Ну вот запустили мы кучу приложух через snap-flatpak
2) Запустили кучу приложух на электроне
3) Чё, нет денег на оперативу?
Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

32. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (32), 26-Июн-23, 13:52 
> В системном вызове open() запрещено одновременное указание флагов O_DIRECTORY и O_CREAT, которое теперь будет приводить к выводу ошибки EINVAL.

*в тишине раздался кашель, сквозь который звучит что-то, напоминающее "we-never-break-userspace"*

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

37. "Релиз ядра Linux 6.4"  +4 +/
Сообщение от llolik (ok), 26-Июн-23, 14:00 
Ну, юзерспейс и не сломан. Флаги на месте, код соберётся и будет работать. Единственное изменение, в данной комбинации флагов возвращается код с ошибкой, которую, теоретически, и так надо-бы было обрабатывать.
Ответить | Правка | Наверх | Cообщить модератору

48. "Релиз ядра Linux 6.4"  –9 +/
Сообщение от Аноним (46), 26-Июн-23, 14:46 
Вы правда думаете, что комментаторы с опеннета что-то пишут на сишечке или близко к ней? Тут же ржавый и гошланг правят бал. :)
Ответить | Правка | Наверх | Cообщить модератору

51. "Релиз ядра Linux 6.4"  +/
Сообщение от Анони (?), 26-Июн-23, 14:52 
Раст теперь потеряет свою безопастность.
Ответить | Правка | Наверх | Cообщить модератору

93. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (93), 26-Июн-23, 18:41 
Можно подумать, на rust и golang ошибки не надо обрабатывать.
Более того, там надо явно выразить желание НЕ обрабатывать :-)
Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

110. "Релиз ядра Linux 6.4"  +1 +/
Сообщение от Прохожий (??), 26-Июн-23, 21:17 
Только на ней, увы, и пишут в подавляющем большинстве. На большее уже не способны.
Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

127. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним. (?), 26-Июн-23, 23:53 
Судя по комментам, тут только на assembler пишут. Ну ладно... Изредка на C, но НИКАКИХ плюсов!
Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

41. "Релиз ядра Linux 6.4"  +2 +/
Сообщение от pavlinux (ok), 26-Июн-23, 14:12 
Они хитрожoпo  это обошли


man open  
ERRORS
       open(), openat(), and creat() can fail with the following errors:

. . .

EINVAL O_CREAT was specified in flags and the final component of the new file's pathname is invalid

. . .

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

42. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (42), 26-Июн-23, 14:18 
А что, что-то сломалось?
Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

45. "Релиз ядра Linux 6.4"  +1 +/
Сообщение от pavlinux (ok), 26-Июн-23, 14:30 
> А что, что-то сломалось?

Они ломают философию UNIX - "Всё  есть файл!"

По-хорошему надо было сделать редирект на mkdir(), а тот бы уж вернул ENOTDIR,
если будут операции невозможные с директориями.

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

97. "Релиз ядра Linux 6.4"  +/
Сообщение от Ananimus (?), 26-Июн-23, 19:16 
Какую философию?

>        O_DIRECTORY
>              If  pathname  is not a directory, cause the open to fail.  This flag was added in Linux 2.1.126, to avoid denial-of-service problems
>              if opendir(3) is called on a FIFO or tape device.

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

171. "Релиз ядра Linux 6.4"  +/
Сообщение от pavlinux (ok), 27-Июн-23, 19:48 
И причём тут opendir() ?
Ответить | Правка | Наверх | Cообщить модератору

185. "Релиз ядра Linux 6.4"  +/
Сообщение от Ananimus (?), 28-Июн-23, 12:37 
Ты мне скажи. Это man 2 open.
Ответить | Правка | Наверх | Cообщить модератору

100. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (98), 26-Июн-23, 19:29 
> сделать редирект на mkdir()

Ну и зачем там это связывание? Чтобы потом правка кода в mkdir() что-нибудь сломала, желательно втихую и с повреждением данных?

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

50. "Релиз ядра Linux 6.4"  +1 +/
Сообщение от mos87 (ok), 26-Июн-23, 14:50 
интересно, амуди когда-нибудь свой pstate доделает, что он уже по умолчанию будет?
Ответить | Правка | Наверх | Cообщить модератору

61. "Релиз ядра Linux 6.4"  –4 +/
Сообщение от Аноним (61), 26-Июн-23, 15:46 
SLOB, SLAB, SLUB... SLOB, SLAB, SLUB... йоу

*читает рэпчик*

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

65. "Релиз ядра Linux 6.4"  +2 +/
Сообщение от Аноним (65), 26-Июн-23, 16:10 
Опеннет 20ХХ год. Релиз ядра Linux 20ХХ. Было принято решение сменить нумерацию ядра на год выпуска соответствующего релиза. Весь код ядра был переписан с устаревшего и небезопасного языка С на безопасный ***. Напомним, что лицензия запрещает его называть, поэтому советом разработчиков ядра на всеобщем голосовании было принято решение дать этому языку кодовое имя ***. За проголосовало 99% представителей, один воздержался.
Ответить | Правка | Наверх | Cообщить модератору

73. "Релиз ядра Linux 6.4"  +/
Сообщение от Kuromi (ok), 26-Июн-23, 16:26 
"В файловой системе Ext4 упрощена огранизация записи журнала (data=journal). Внесены оптимизации, связанные с предварительным распределением inode, позволившие ускорить работу в системах, в которых выполняется большое число случайных операций записи. Операции чтения и записи страниц памяти переведены на использование фолиантов страниц памяти (page folios)."

А когда ожидается поддержка аттрибута "безопасное удаление", чтобы без shred обходиться? (сарказм)

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

78. "Релиз ядра Linux 6.4"  +6 +/
Сообщение от Анонин (?), 26-Июн-23, 16:35 
> удалена опция монтирования "noacsrules", которая была некорректно реализована.

ахаха, лучший багфикс эвер!

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

81. "Релиз ядра Linux 6.4"  +/
Сообщение от Самый умный из вас (?), 26-Июн-23, 16:50 
Чем теперь tmpfs+noswap будет отличаться от ramfs?
Ответить | Правка | Наверх | Cообщить модератору

103. "Релиз ядра Linux 6.4"  +1 +/
Сообщение от Kuromi (ok), 26-Июн-23, 19:54 
Тем что у ramfs фиксированный размер в памяти (сколько задали, не больше не меньше) и есть оверхед на форматирование.
Ответить | Правка | Наверх | Cообщить модератору

117. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (117), 26-Июн-23, 22:18 
не путайте ramfs с ram block device
Ответить | Правка | Наверх | Cообщить модератору

115. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (117), 26-Июн-23, 22:16 
вангую скоро выпилят ramfs
Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

83. "Релиз ядра Linux 6.4"  +2 +/
Сообщение от Хру (?), 26-Июн-23, 17:05 
Неотключаемый selinux? А как же тогда гугловский Project Zero любым примитивом на запись его отключает? И почему с этим ничего не сделать?
Ответить | Правка | Наверх | Cообщить модератору

85. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним123 (?), 26-Июн-23, 17:23 
Кто понял про этот LAM_57 режим? Могу ли я эти "лишние" биты использовать в своём user-space приложении например чтобы узнать, что помять не попорчена?
Ответить | Правка | Наверх | Cообщить модератору

86. "Релиз ядра Linux 6.4"  +/
Сообщение от pavlinux (ok), 26-Июн-23, 17:40 
> Могу ли я

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

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

89. "Релиз ядра Linux 6.4"  –1 +/
Сообщение от Аноним (89), 26-Июн-23, 18:17 
>Добавлена поддержка предоставляемого в процессорах Intel режима LAM_U57 (Linear Address Masking), позволяющего использовать часть битов 64-разрядных указателей (c 57 по 62 биты) для хранения не связанных с адресацией метаданных.

Ага. А потом "прекращена поддержка процессоров без LAM". Новые процессоры (а  с ними и компьютеры целиком) себя сами не купят. Подобные вредительские инициативы нв корню рубить надо.

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

94. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (54), 26-Июн-23, 18:42 
Фигасе далеко идущие выводы. Что там в ядре до сих пор поддерживается? i686?
Ответить | Правка | Наверх | Cообщить модератору

132. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (132), 27-Июн-23, 02:39 
1. не в ядре, а в прикладном софте. хотят хранить в указателях доп. инфу - могут использовать структуры struct fat_pointer {void * ptr; uint8_t bullshit[as_much_as_needed];}; и проверять их x86-кодом.
2. до ядра это тоже доберётся. i486 же дропнули. good riddance, как Линус сказал.

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

139. "Релиз ядра Linux 6.4"  –2 +/
Сообщение от Аноним (54), 27-Июн-23, 05:18 
30+ летнюю архитектуру дропнули, как теперь жить.
Ответить | Правка | Наверх | Cообщить модератору

209. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (209), 09-Июл-23, 07:07 
Самое смешное, что стоны про то, что дропнули i486 раздаются от тех, кто в силу возраста или нищеты в 90ых не застал i486 вообще
А те кто застал совершенно плевать хотели на то, что дропнули процессоры, которые были 25 лет назад, ведь эти процессоры давно на помойке
Ответить | Правка | К родителю #132 | Наверх | Cообщить модератору

158. "Релиз ядра Linux 6.4"  –2 +/
Сообщение от Tron is Whistling (?), 27-Июн-23, 09:22 
Да и i686 давно пора дропнуть.
Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

91. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (91), 26-Июн-23, 18:40 
>  slab SLAB

Насколько сейчас актуальны параметры командной строки ядра  `slab_nomerge` и `slub_debug=FZ`?

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

101. "Релиз ядра Linux 6.4"  +1 +/
Сообщение от Аноним (-), 26-Июн-23, 19:47 
>Одновременно латиноамериканский Фонд свободного ПО сформировал вариант полностью свободного ядра 6.4 - Linux-libre 6.4-gnu, очищенного от элементов прошивок и драйверов, содержащих несвободные компоненты или участки кода, область применения которых ограничена производителем

Приятно видеть как наши товарищи из Латинской Америки сохраняют революционную сознательность.

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

150. "Релиз ядра Linux 6.4"  +/
Сообщение от Прохожий2 (?), 27-Июн-23, 06:57 
Вот бы ещё весь хлам выпиливали
Ответить | Правка | Наверх | Cообщить модератору

108. "Релиз ядра Linux 6.4"  +4 +/
Сообщение от Атон (?), 26-Июн-23, 20:56 
> Добавлена поддержка предоставляемого в процессорах Intel режима LAM_U57 (Linear Address Masking), позволяющего использовать часть битов 64-разрядных указателей (c 57 по 62 биты) для хранения не связанных с адресацией метаданных. Для обычных программ не требуется столько памяти,

1) "640кб хватит всем"
2) хак завязанный на особенности реализации и поведения железа.
3) Дремучее legacy родилось на наших глазах.

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

119. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (119), 26-Июн-23, 22:33 
>> (c 57 по 62 биты) для хранения не связанных с адресацией метаданных. Для обычных программ не требуется столько памяти,
> 1) "640кб хватит всем"

С одной стороны да, но 2^57 = 144 петабайта, если я не ошибся. Ограничения в 144 петабайт ОЗУ, при том, что в микроэлектронике мы уже уперлись в серьезные ограничения по размеру элементов, их соединений и, соответственно, их плотности упаковки и теплоотдачи, наверное лет на двадцать хватит минимум. Разве что изобретут что-то революционное, принципиально отличное от существующих технологий.

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

125. "Релиз ядра Linux 6.4"  +1 +/
Сообщение от Тот_ещё_аноним (ok), 26-Июн-23, 23:47 
>> лет на двадцать хватит минимум

Срок реально небольшой, чтобы каку зарывать

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

133. "Релиз ядра Linux 6.4"  +1 +/
Сообщение от Аноним (132), 27-Июн-23, 02:40 
Intel бы с радостью и на год каку зарыла. Новые камни сами собой не купятся.
Ответить | Правка | Наверх | Cообщить модератору

156. "Релиз ядра Linux 6.4"  +1 +/
Сообщение от Атон (?), 27-Июн-23, 08:59 
>>> (c 57 по 62 биты) для хранения не связанных с адресацией метаданных. Для обычных программ не требуется столько памяти,
>> 1) "640кб хватит всем"
> С одной стороны да, но 2^57 = 144 петабайта, если я не
> ошибся. Ограничения в 144 петабайт ОЗУ,

не "ОЗУ", а в аппаратной адресации. Это большая разница.

Мало тебе MemoryHole  640кб-1Mb,  15-16M, теперь и это добавили.


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

https://i.pinimg.com/originals/d1/f1/db/d1f1db3ec965a65f5c16...

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

173. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (119), 28-Июн-23, 02:27 
> не "ОЗУ", а в аппаратной адресации. Это большая разница.

Ты хочешь сказать, что при 144-петабайтной адресации надо учитывать объем легаси-дыр? Ты хочешь сказать, что все эти твои дыры из адресации сожрут 143 пертабайта и на "реальную ОЗУ" у тебя останется жалкий петабайт? Думаю, согласишься, что нет.

Так что этими дырами можно пренебречь и повторить утверждение, что 144 петабайт озу это дофига и даже наверное недостижимо при существующих и "ближнебудущных" технологиях - частоты, предельные размеры элементов (даже когда перейдем на маркетинговые "2нм" года через 3-5). Да и разносить элементы далеко друг от друга ты сможешь только в ущерб скорости - скорость света же ограничена. Например, при тактовой частоте в 3 ГГц за один такт электромагнитная волна может пройти всего 10 сантиметров. Удачи тебе собрать ОЗУ на 100 петабайт по технологии "2 нм", скомпоновать всё это настолько компактно, чтобы можно было бы хотя бы, условно, на 1 ГГц с ней работать, а потом еще, с такой черепашьей скоростью, попробуй по полной загрузить это ОЗУ данными и работать со всеми 100 петабайтами.


> https://i.pinimg.com/originals/d1/f1/db/d1f1db3ec965a65f5c16...

Не совсем понятно к чему это. А теперь давай хотя бы 10 петабайт (124 петабайта адресации оставим на дыры) вот такой памяти как на этой фотке. Интересно, планеты тебе хватит? Если ты пытался намекнуть "что было вот, а стало - вот, так что не бойся, так будет и дальше" - огорчу - технологии уже уперлись в пределы, где размеры элементов или их компонентов уже десятками атомов считаются. Дальше уменьшать уже сложно - там всякие квантовые, туннельные эффекты и прочее г.вно, уже проявляются значительно сильнее и система становится крайне нестабильной.

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

191. "Релиз ядра Linux 6.4"  +/
Сообщение от Атон (?), 28-Июн-23, 17:30 
>> не "ОЗУ", а в аппаратной адресации. Это большая разница.
> Ты хочешь сказать, что при 144-петабайтной адресации надо учитывать объем легаси-дыр?

я прямо говорю что при любой адресации, любая дыра это не есть хорошо.  
сколько десятилетий "аукались" те дыры, даже уже после выхода десятков поколений нового железа?

легаси.  
суровое наследие, поддерживаемое для совместимости.


>  - скорость света же
> ограничена. Например, при тактовой частоте в 3 ГГц за один такт
> электромагнитная волна может пройти всего 10 сантиметров.

8 см. скорость света зависит от среды.  в плотной среде - медленнее. для электромагнитных волн есть среды замедляющие их скорость в сотни раз.

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


> компактно, чтобы можно было бы хотя бы, условно, на 1 ГГц

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

> попробуй по полной загрузить это ОЗУ данными и работать со всеми 100
> петабайтами.

сериализовать Большую Советскую Энциклопедию на JS, и придется еще свапится.


>> https://i.pinimg.com/originals/d1/f1/db/d1f1db3ec965a65f5c16...
> Не совсем понятно к чему это.

это говорит о твоем узком кругозоре.

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

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


фотография сделана в то время, когда такие как ты, говорили что сделать больше 16 килобайт в компактном размере невозможно.  
человек на фото запихнул в равный объем 4 мегабайта, решив проблемы питания охлаждения и др.

всегда найдется тот, кто сделает сегодня то, что ты считаешь невозможным даже завтра.

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

200. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (199), 01-Июл-23, 13:40 
> я прямо говорю что при любой адресации, любая дыра это не есть хорошо.

Ну, поставить атрибуты в MMU и дело с концом. Он эксепшн кинет, какое ему дело. Ну и юзерский софт работает с виртуальными адресами же, физические, с дыркой, только ядро и видит.

> уже есть терагерцовая электроника.

Ну так на допустим 10-40ГГц сто лет как есть для спутниковых коммуникаций и микроволновых линков. Не означает что проц на такой частоте будет работать. Там основной лимит это нагрев вообще, слишком быстрая схема с вольтажом потребным для стабильной работы на этой скорости на данном техпроцессе - тупо перегревается. В это все и упирается. Ну а на 10ГГц реально загнать только какой-то относительно примитивный чип с небольшим числом элементов, соответственно. А миллиарды транзисторов переключать на таких частотах - вопрос в энергии на переключение и количестве.

> сериализовать Большую Советскую Энциклопедию на JS, и придется еще свапится.

Сейчас базы и сильно поболее этого. Да и зачем при сериализации гигазы рамы?

> через короткое время будет в продаже на массовом рынке.

Этой прохладной истории уже более десятка лет, между прочм.

> всегда найдется тот, кто сделает сегодня то, что ты считаешь невозможным даже завтра.

А можно мне уже нормальных источников энергии? Ну вот задолбали батарейки сделаные человечеством, самый негодный аспект развития человечества пока. Каждый год обещают что вот вот станет ЗБС. И такая хрень уже более 20 лет для одного только лития. А реально вон там лопатники которые в карман не лезут состоящие из по сути батарейки, и даже так в обнимку с паварбанком - иначе за день выдыхается.

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

109. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (109), 26-Июн-23, 21:12 
В последнее время nvme под систему хватает с избытком, поэтому и swap = 2x ram и 30% не размечаю. И выполняю заветы олдов, без понимания. И комментарии как то ясности не добавили. Есть новый завет?
Ответить | Правка | Наверх | Cообщить модератору

151. "Релиз ядра Linux 6.4"  –1 +/
Сообщение от n00by (ok), 27-Июн-23, 07:04 
Если используете гибернацию, размер подкачки желателен не меньше ОЗУ (хотя нередко достаточно столько, сколько ОЗУ занято). Если не используете, посмотрите, сколько в подкачке по максимуму бывает, из этого исходите. Если вдруг сильно понадобится подкачка, на популярных ФС её можно добавить, создав ещё файл. Про резерв 30% не знаю, что и сказать - производитель и без этого предусмотрел резерв. Экспертами платят торговцы железом, так что надо стимулировать спрос.
Ответить | Правка | Наверх | Cообщить модератору

166. "Релиз ядра Linux 6.4"  +/
Сообщение от Чукча (?), 27-Июн-23, 17:40 
Однажды изучив технологию ssd, всю жизнь имели бы на 30% больше дискового пространства.
Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

114. "Релиз ядра Linux 6.4"  +1 +/
Сообщение от YetAnotherOnanym (ok), 26-Июн-23, 22:07 
> возможность создания работающих на уровне ядра обработчиков (kernel worker) из процессов в пространстве пользователя. (...) Реализация оптимизирована для совместного использования с io_uring.

Раздолье-то какое, раздолье!

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

155. "Релиз ядра Linux 6.4"  +/
Сообщение от onanim (?), 27-Июн-23, 08:59 
> возможность создания работающих на уровне ядра обработчиков (kernel worker) из процессов в пространстве пользователя

астрологи объявили неделю LPE уязвимостей

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

116. "Релиз ядра Linux 6.4"  –1 +/
Сообщение от YetAnotherOnanym (ok), 26-Июн-23, 22:16 
> В интерфейсе асинхронного ввода/вывода io_uring появилась возможность одновременной прямой записи в файл в несколько потоков

А диск такой: "В очередь, с*кины дети, в очередь!".
Чем-то напоминает "менеджеры загрузок" эпохи диалапа, когда хомячки верили, что скачивание файла в несколько потоков позволит преодолеть лимит скорости модема.

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

118. "Релиз ядра Linux 6.4"  +3 +/
Сообщение от Аноним (54), 26-Июн-23, 22:30 
Походе, ни о временах диалапа, ни о нынешних накопителях вы ничего не знаете.
Ответить | Правка | Наверх | Cообщить модератору

159. "Релиз ядра Linux 6.4"  +/
Сообщение от YetAnotherOnanym (ok), 27-Июн-23, 10:58 
Если Вас так задели мои слова, у вас есть шанс блеснуть познаниями по части менеджеров загрузки и современных накопителях.
Ответить | Правка | Наверх | Cообщить модератору

122. "Релиз ядра Linux 6.4"  +3 +/
Сообщение от Аноним (122), 26-Июн-23, 23:16 
Позволяло если админ на той стороне ставил ограничение на скорость отдачи ниже лимита скорости модема. Проверено лично и неоднократно.
Ответить | Правка | К родителю #116 | Наверх | Cообщить модератору

124. "Релиз ядра Linux 6.4"  +2 +/
Сообщение от Аноним (54), 26-Июн-23, 23:37 
Вообще говоря, оно и сейчас много где актуально.
Ответить | Правка | Наверх | Cообщить модератору

144. "Релиз ядра Linux 6.4"  +1 +/
Сообщение от фф (?), 27-Июн-23, 06:34 
еще помогало, если линия не очень хорошая и часто возникали ошибки передачи. Пока один поток перезапрашивает кусок, файла линия простаивает, и второй в это время спокойно качает свою часть.
Ответить | Правка | К родителю #122 | Наверх | Cообщить модератору

162. "Релиз ядра Linux 6.4"  +1 +/
Сообщение от Аноним (162), 27-Июн-23, 12:43 
Так этож преодоление ограничений отдающего, а не ограничения скорости собственного модема.
Ответить | Правка | К родителю #122 | Наверх | Cообщить модератору

152. "Релиз ядра Linux 6.4"  +1 +/
Сообщение от n00by (ok), 27-Июн-23, 07:11 
В эпоху диалапа не каждый браузер знал про Accept-Ranges, и докачка (после обрыва соединения) работала в основном в менеджерах.
Ответить | Правка | К родителю #116 | Наверх | Cообщить модератору

165. "Релиз ядра Linux 6.4"  +/
Сообщение от Чукча (?), 27-Июн-23, 17:37 
Вас уже обваляли в фикалиях по части диалапа. Бодбодрю жижу, в которой плескаетесь, со своей стороны:
для файла, занимающего страницы (по 4K), относящиеся к различным блокам страниц (~по 128 страниц) на диске, современный контроллер без сложностей обеспечит асинхронную параллельную запись.
Ответить | Правка | К родителю #116 | Наверх | Cообщить модератору

170. "Релиз ядра Linux 6.4"  +/
Сообщение от YetAnotherOnanym (ok), 27-Июн-23, 19:37 
Здесь нашлось несколько индивидов, которые любят набрать в рот фекалий, чтобы плюнуть в сторону оппонента. На это забавно смотреть со стороны, особенно, когда к процессу присоединяются новые участники.
Ответить | Правка | Наверх | Cообщить модератору

189. "Релиз ядра Linux 6.4"  +/
Сообщение от Чукча (?), 28-Июн-23, 14:49 
И не говорите. Ещё забавней наблюдать, как Вы в этих фикалиях плескаетесь, будучи не способным на контраргументацию, а лишь продолжая множить свои заблуждения.
Ответить | Правка | Наверх | Cообщить модератору

193. "Релиз ядра Linux 6.4"  +/
Сообщение от YetAnotherOnanym (ok), 28-Июн-23, 21:03 
Да что ж Вам всё неймётся-то? Всё плюётесь и плюётесь...
Ответить | Правка | Наверх | Cообщить модератору

195. "Релиз ядра Linux 6.4"  +/
Сообщение от Чукча (?), 28-Июн-23, 22:43 
Пока Вы так прелестно плескаетесь, хочется только подливать.
Ответить | Правка | Наверх | Cообщить модератору

172. "Релиз ядра Linux 6.4"  +/
Сообщение от Tron is Whistling (?), 27-Июн-23, 23:47 
У скачивания файла в несколько потоков с быстрых серверов по диалапу было и есть вполне себе резонное объяснение.
К любимому мной 2G ныне всё настолько же применимо.
Дело кроется в регулярных потерях пакетов на сверхмедленном канале, а особенно - tcp ack, при приличном значении roundtrip latency.
Дальше объяснять не буду.
Ответить | Правка | К родителю #116 | Наверх | Cообщить модератору

121. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (122), 26-Июн-23, 23:14 
Молодцы корпорации. Хорошо потрудились.
Ответить | Правка | Наверх | Cообщить модератору

126. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (126), 26-Июн-23, 23:50 
да... и любой сможет этим пользоваться...
Ответить | Правка | Наверх | Cообщить модератору

163. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (122), 27-Июн-23, 15:56 
Я и говорю - молодцы. Должен же кто-то и само опенсорсие писать хотя бы ради прикола, а не 4 свободы и прочие лозунги.
Ответить | Правка | К родителю #121 | Наверх | Cообщить модератору

183. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (183), 28-Июн-23, 10:32 
Не потрудились, а оплатили. И оплатили строго говоря тоже не корпорации, а их клиенты. Корпорация - посредник и паразит.
Ответить | Правка | К родителю #121 | Наверх | Cообщить модератору

160. "Релиз ядра Linux 6.4"  +/
Сообщение от Cyber100email (ok), 27-Июн-23, 11:26 
из всего я не понял - btrfs raid 5/6 уже можно или еще рано?
Ответить | Правка | Наверх | Cообщить модератору

164. "Релиз ядра Linux 6.4"  +1 +/
Сообщение от Чукча (?), 27-Июн-23, 17:23 
Если бы в самом деле хотели понять, то обратились бы к документации на kernel.org.
Как и ранее, для данных можно, для метаданных не рекомендуется. Для метаданных следует применять raid1, raid10, raid1c3, raid1c4. Для последних двух формат хранения ещё не зафиксирован.
Ответить | Правка | Наверх | Cообщить модератору

167. "Релиз ядра Linux 6.4"  +/
Сообщение от Cyber100 (ok), 27-Июн-23, 17:46 
спасибо тебе, язвительный чел. обо всем этом я знаю.
Ответить | Правка | Наверх | Cообщить модератору

186. "Релиз ядра Linux 6.4"  +1 +/
Сообщение от Чукча (?), 28-Июн-23, 14:39 
Может знаешь, а может и нет. Правда неизвестна, есть только твой вопрос в начале ветки и отписка на мой ответ.
Ответить | Правка | Наверх | Cообщить модератору

177. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (-), 28-Июн-23, 08:36 
> Для последних двух формат хранения ещё не зафиксирован.

Это с чего это не зафиксирован? Никто это уже ломать не собирается, вы чего. Из изменений V2 формата там скорее множественные экстентные деревья хотели и т.п. - сейчас в массово параллельной нагрузке с 1 деревом - lock contention случается, неоптимально по скорости, актуально для суперскоростных энтерпрайзных SSD.

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

187. "Релиз ядра Linux 6.4"  +/
Сообщение от Чукча (?), 28-Июн-23, 14:41 
Ломать может и не собираются, но формат raid1c3 и raid1c4 остаётся не зафиксированным.
Ответить | Правка | Наверх | Cообщить модератору

201. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (199), 01-Июл-23, 13:44 
> Ломать может и не собираются, но формат raid1c3 и raid1c4 остаётся не > зафиксированным.

Где это написано?

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

169. "Релиз ядра Linux 6.4"  +/
Сообщение от DEF (?), 27-Июн-23, 19:22 
Давно можно. Метаданные хранишь на RAID1 (Подойдут 1TB диски, которые можно купить за копейки), а данные на RAID5/6. Все работает как часы.
Ответить | Правка | К родителю #160 | Наверх | Cообщить модератору

188. "Релиз ядра Linux 6.4"  +/
Сообщение от Чукча (?), 28-Июн-23, 14:44 
Для какого размера массива данных Вы предлагаете 1 Тбайт под метаданные?
Ответить | Правка | Наверх | Cообщить модератору

196. "Релиз ядра Linux 6.4"  +/
Сообщение от DEF (?), 29-Июн-23, 15:01 
1 к 20-25 примерно. Зависит от выбранного алгоритма чексумм и от самих данных. Если очень много файлов маленького размера - они могут храниться в метаданных.
Ответить | Правка | Наверх | Cообщить модератору

197. "Релиз ядра Linux 6.4"  +/
Сообщение от Чукча (?), 29-Июн-23, 23:34 
Вы дикость пишите. Для записи 1 Тбайт данных потребуется от силы 4 Гбайт метаданных, что есть 0.4%. Но никак ни 4-5% как утверждаете Вы.
Ответить | Правка | Наверх | Cообщить модератору

198. "Релиз ядра Linux 6.4"  +/
Сообщение от DEF (?), 01-Июл-23, 01:12 
Чукча не читатель, чукча писатель?

Btrfs данные маленьких файлов может хранить в метаданных. Мануалы кури, чукча.

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

202. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (199), 01-Июл-23, 13:48 
> Для какого размера массива данных Вы предлагаете 1 Тбайт под метаданные?

Вы явно не понимаете как RAID5/6 работает вообще - и тем более "file based" btrfs инкарнация в частности. Иначе не понятно откуда реверанс про терабайт под метаданные. Btrfs аллоцирует чанки данных и метаданных юнитами порядка нескольких гигз, блочные группы для данных или метаданных, в том или ином формате. Сколько ему будет надо под метаданные - столько и аллоцирует, если это место вообще было.

Откуда тут терабайт на метаданные берется в хоть каких-то факторах - кто ж его знает.

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

176. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (-), 28-Июн-23, 08:34 
RAID5 с метаданными в RAID1 - почему нет? У RAID6 write hole пока еще есть, до конца еще не заткнута. Другое дело что вон то сделано недавно, оттестированость пока еще скромная.
Ответить | Правка | К родителю #160 | Наверх | Cообщить модератору

175. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (175), 28-Июн-23, 05:32 
Зачем писать код ядра на Rust, когда его можно писать на BPF?
Ответить | Правка | Наверх | Cообщить модератору

182. "Релиз ядра Linux 6.4"  –1 +/
Сообщение от Аноним (182), 28-Июн-23, 10:01 
> Из ветки Rust-for-Linux продолжен перенос дополнительной функциональности, связанной с использованием языка Rust в качестве второго языка для разработки драйверов и модулей ядра

Так Linux превращают в ведро для помоев

> Одновременно латиноамериканский Фонд свободного ПО сформировал вариант полностью свободного ядра 6.4 - Linux-libre 6.4-gnu, очищенного от элементов прошивок и драйверов, содержащих несвободные компоненты или участки кода, область применения которых ограничена производителем.

А патч для очистки Linux от ржавчины где?

> В хранилище ключей (keyring) ".machine" реализован режим, допускающий размещения только ключей, заверенных цифровой подписью известного системе удостоверяющего центра. Хранилище ".machine" содержит ключи владельца системы (MOK, Machine Owner Keys), используемые в shim-загрузчике и применяемых для заверения цифровой подписью компонентов ядра, загружаемых на стадии после начальной загрузки, например, модулей ядра. Новый режим нацелен на предоставление возможности размещения в хранилище ".machine" ключей, используемых в подсистеме IMA (Integrity Measurement Architecture), предназначенной для проверки целостности компонентов операционной системы по цифровым подписям и хэшам.

Мне интересна политика IBM/Linux в отношении ключей IMA/EVM:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

Для гарантирования безопасной цепочки загрузки необходимо и достаточно хранение публичных ключей IMA/EVM в ядре Linux (добавляются во время компиляции ядра) и проверки ядра публичным ключом из GRUB. Ключи прописываются в:
CONFIG_EVM_X509_PATH    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
CONFIG_IMA_X509_PATH    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
и
CONFIG_MODULE_SIG_KEY    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Сами все эти ключи, если установлена опция INTEGRITY_TRUSTED_KEYRING подписаны основным ключом ядра:
CONFIG_SYSTEM_TRUSTED_KEYS    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

В тоже время текущая реализация, почему-то ищет ключи IMA/EVM в аппаратном TPM, и если не находит то использует ключ HMAC.

Проблемка есть также в файловой системе tmpfs, в которую грузится initramfs и в cpio которым опакечен initramfs -- они не поддерживают xattr и следовательно негде хранить хеши/подписи файлов для проверки IMA/EVM. Приходится менять политику IMA/EVM для поддержки initrd.

добавление всей этой кампании ключей https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... не рекомендую, она излишня.

Предполагаю что всё это затеяно для исключения GRUB. Другие загрузчики не поддерживают загрузку с шифрованных разделов и верификацией загрузки модулей, настроек, ядра и initrd.

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

190. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (190), 28-Июн-23, 17:11 
> добавление всей этой кампании ключей https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... не рекомендую, она излишня.

Ключи в ядре лишними не бывают, каждой *Б надо иметь в ведре свой ключ для подписи своего rootkit:
https://www.linux.org.ru/forum/admin/15194240?cid=15194473
https://www.linux.org.ru/forum/admin/15194240?cid=15195110
https://www.linux.org.ru/forum/admin/15194240?cid=15195123
https://www.linux.org.ru/forum/admin/15194240?cid=15195132

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

203. "Релиз ядра Linux 6.4"  +/
Сообщение от Аноним (199), 01-Июл-23, 13:51 
> А патч для очистки Linux от ржавчины где?

А оно опциональное при сборке. И там вроде пока даже и очищать особо нечего.

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

204. "Релиз ядра Linux 6.4"  +/
Сообщение от qux (ok), 01-Июл-23, 20:09 
> Предполагаю что всё это затеяно для исключения GRUB. Другие загрузчики не поддерживают
> загрузку с шифрованных разделов и верификацией загрузки модулей, настроек, ядра и
> initrd.

Не поддерживают {загрузку с шифрованных + верификацию}, или только первое? Для корня в LUKS поддержки загрузчиком вроде никакой не нужно

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

208. Скрыто модератором  +/
Сообщение от Верочка (??), 07-Июл-23, 03:18 
Ответить | Правка | Наверх | Cообщить модератору

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

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




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

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