После двух месяцев разработки Линус Торвальдс представил релиз ядра Linux 6.4. Среди наиболее заметных изменений: возможность создания kernel worker из пространства пользователя, продолжение интеграции поддержки языка Rust, поддержка механизма Intel LAM (Linear Address Masking), дедупликация страниц памяти на уровне процессов, поддержка привычных итераторов в BPF, поддержка перехода в спящий режим для систем RISC-V, возможность трассировки пользовательских процессов, новый механизм управления памятью модулей ядра, запрет отключения SELinux во время работы, поддержка шифрования RPC-пакетов NFS, удаление SLOB slab allocator...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=59344
> поддержки дедупликации осуществляется через prctl(PR_SET_MEMORY_MERGE) для процесса целиком
> и наследуется для дочерних процессов, без необходимости активации для каждого диапазона памяти ...Товарищ Майор будет рад
> В интерфейсе асинхронного ввода/вывода io_uring появилась возможность одновременной ...
Танцуем танго и нижний брейк, но одновременно :))
> Вместо SLOB следует использовать SLUB или SLAB.
SLAB уже с фейсбучными патчами?
> В XFS добавлены изменения, необходимые для реализации проверки ФС на лету
Лет через 5 можно будет юзать
> Реализован универсальный программный интерфейс для управления светодиодными индикаторами на сетевых коммутаторах или сетевых платах.
Ждём видосики: рубимся в Doom на стойке из Cisco .
> В драйвере MediaTek MT76 добавлена поддержка WiFi 7.
Wifi 6 уже все попробовали? :)
> Товарищ Майор будет радА что оно ему дает? Экономию RAM? Это не только майорам нравится. В остальных случаях нельзя ли поподробнее чем это кому грозит?
> Танцуем танго и нижний брейк, но одновременно :))
А был бы у тебя хвост, смог бы и еще чего-нибудь заодно.
> Лет через 5 можно будет юзать
Да юзать то можно хоть сейчас. Но с их управлением девайсами толку с этого...
> Ждём видосики: рубимся в Doom на стойке из Cisco .
Это, типа, из их светодиодиков экран для дума собрать? Типа, как на здании в тетрис светом в комнатах играли? Ох, мсье знает толк...
> Wifi 6 уже все попробовали? :)
Тсс, не мешай ящеркам палиться. И попроси у них нормальные батарейки в следующий раз. И хрен с ним, с гигабитами через подпространство.
>Товарищ Майор будет радОсобенно майор Джонс...
Столлман завещал пилить хурд. Вы не послушались заветов Столлмана. Результат на лицо.
Только он сам Хурд никогда не пилили, да и архитектор из него так себе. Хурд можно только переписать с нуля.
так он вроде архитектурный и не заканчивал
На бытовых железках оно всё равно никогда работать нормально не будет. Server only.
а если и будет на какой-то одной (стим дек, например), никто тебе никогда не даст гарантий что всё будет так же продолжаться десятилетиями, как с виндой
Ну да, в любой момент что-нибудь да отвалится. На моём актуальном компьютере оно либо вообще не загружается в лайв режиме даже, либо наглухо виснет на этапе установки. Вот, что значит стабильность - за 20 лет так ничего и не изменилось.
расскажи это моему смартфону...
У него и на смартфоне ничего работать не будет. А виноваты все кроме него.
В таком случае FreeBSD - самая популярная в мире игровая платформа, ведь её ядрышко крутится в топовых консолях. Не забудем и о премиальном сегменте десктопов и смартфонов от Apple.
На домашнем десктопе последние Ubuntu или Fedora у меня вроде нормально работают:
https://opennet.ru/59007-ubuntu
https://opennet.ru/58995-fedora
>Удалён SLOB (slab allocator), устаревший механизм распределения памяти slab, который был спроектирован для систем с небольшим объёмом памяти.и чо типерь делать? вот как типерь быть? дальше быть на debian 10.0? а патом куда периходить?
а чем тебе 12-тый не устраивает?
Тем, что он не 12.0.1
ну тогда страдай¯\_(%)_/¯
SLOB это вообще не для десктопов, а для embedded.
> SLOB это вообще не для десктопов, а для embedded.Им и там уже никто не пользовался сто лет как правило.
Мне вот другое интересно с этой дедупликацией памяти.
1)Ну вот отдедуплицировали три блока. Получили 1.
2)Вносим в 2 блока изменение, а памяти на раздупликацию, внезапно нетути.
3)?
OOM, убиваем что ненужно :-D
> OOM, убиваем что попало!Все убитое - объявляем ненужно.
поправил, не благодари.
> Все убитое - объявляем ненужно.
> поправил, не благодари.При том у тех кто не любит RTFM оно будет убиваться по рандому. Более разумные существа которым так не нравится - прочитают про oom score adjust.
А если кого волновали вон те случаи, в линухе ПО ДЕФОЛТУ врублен OVERCOMMIT. Если кто не знает - он позволяет программам заказывать больше памяти чем реально есть в надежде что они не будут по факту это юзать, при том в большей части это весьма обосновано, достаточно сравнить RSS vs VSZ и сделать выводы о том что в вон том фокусе есть пойнт. Однако всегда возможна ситуация что прога захотела поюзать новую страницу - упс, ее нет, упс, если не ошибаюсь, SIGSEGV. В свете чего не понятно что вон то меняет в дефолтном поведении... кроме того что больше прог удастся запустить.
Если кому это поведение критично - так оно настраивается. И вон то и оверкомит.
swap
SWAP - это худший костыль компьютерной индустрии и он должен умереть.Впрочем, на моих компах и серверах (> 200, high-load, >100 запросов в секунду) он выключен. Полёт отличный!
В Линукс зачем-то hibernate = swap, но это безумие и, надеюсь, hibernate отделят. Впрочем, и hibernate с приходом SSD/NVMe потерял актуальность.
Ты просто залил проблему железом. Есть задачи где так просто не сделать. А своп это то что позволяло шевелится 95 шинды на компе с 4 мегами оперы.
осталось найти такой комп и задачи для 95ой шинды...а так да...
Своп это то что сегодня позволяет играть в компьютерные игры с хорошими текстурами и без видеокарты с 16гб видеопамяти. В процессе это незаметно, только подгрузки уровня подольше (иногда очень подольше, но сами уровни не лагают).
Он всё правильно написал, своп — это костыль для решения проблемы нехватки ресурсов. Да и всё это разделение на кэш процессора, RAM и диск само по себе убогий костыль, существующий только из-за того, что читать/писать с/на ППЗУ с частотой CPU пока не научились. И эти костыли с нами надолго.
Ну смотри, даже в играх требование файла подкачки или отказывается работать, независимо от того сколько у тебя памяти. Разработчики адекватно рассудили, что неиспользуемые ресурсы неплохо бы вытеснить из памяти. На практике своп решает такие вопросы как утечки памяти в видеодрайвере. Ты либо каждый день перезапускаешь систему, либо раз в год с включённым свопом.
А в мобильниках/embedded он тоже используется? Посмотрим как быстро от него нaкроется NAND/eMMC
> А в мобильниках/embedded он тоже используется?Там zram же используется, вроде как. Что, в принципе, тоже swap, но только в RAM.
Назначение zram другое. Это не замена свопа
зато у свопа поверх zram назначение такое же как и у свопа поверх любого другого блочного устройства
Я тоже так по началу думал..., а оказалось, что нет - скорее это просто СВОП...
Так и работают эти ваши мобильники и ембеддед прям скажем так себе.
Уж лет 15 SSD используются, а народ всё своп на HDD переносит.
SSD за эти 15 лет лучше не стали.
SSD сейчас сильно лучше чем были 15 лет назад инфа сотел.
Сейчас намного лучше контроллеры и алгоритмы, а вот сама память - хуже.
> SSD сейчас сильно лучше чем были 15 лет назад инфа сотел.Особенно дешевые TLC - так что на весь интернет стоит вой от разваленных файлух, когда оно чото протирается - и довольно быстро :)
купил на али 1тб за 2к руб, тупо под торренты, чтобы винты не шуршали, сдохнет да и пофиг, перекачаю, если у людей мозгов нет и они хранят ценные данные на дешевых носителях так кто теперь виноват?
Пользуюсь Samsung 850 Pro на 240 гигов более 7 лет, не отключав "подкачку", "профили браузера" и прочую чушь что советовали когда то давно. Чего я с ним только не делал, и оффтопик стоял, и линь поднимал, некоторые игры на нём держал что бы быстрее запускать. Работает замечательно и по сей момент
А сколько запись? У меня и без свопа 200+ гигабайт за день в норме (и они понятное дело пишутся в одни и те же 100 мегабайт). Я слышал, Самсунги очень быстро дохнут под нагрузкой, своп это не та нагрузка всё же. И проблема Самсунгов, что не угадаешь, какой нормальный, а какой мусорный. А какой вообще сдохнет просто так.
у меня какой-то интел на 40гигов. даже не полмню с каким типом памяти.
Соответственно свопа у меня 40 гигов. 10 лет полет нормальнрый. До этого года три работал системным.
Это называется "систематическая ошибка выжившего".
Возможно, но меня устраивает
Может действительно повезло, а может просто свап пишется равномерно и износ всего диска тоже идет равномерно. А если умрет - то и не жалко.
Контроллер SSD всё пишет равномерно. Своп там, кэш браузера или блюрей с порнухой — ему наплевать. А по сравнению со всем остальным количеством записей в своп можно пренебречь: это во времена вышеупомянутой Win95 с 4 МБ своп использовался действительно активно, а сейчас нет особой проблемы использовать количество оперативки, необходимое для наших задач.
> Контроллер SSD всё пишет равномерно. Своп там, кэш браузера или блюрей с
> порнухой — ему наплевать.Зато не наплевать как это пишется и своп в этом не особо удачная штука, много мелких рандомных записей для износа SSD не подарок.
> А по сравнению со всем остальным количеством записей
> в своп можно пренебречь: это во времена вышеупомянутой Win95 с 4
> МБ своп использовался действительно активно, а сейчас нет особой проблемы использовать
> количество оперативки, необходимое для наших задач.Все это зависит от характера задач. И если какая-то пакость уйдет вразнос, дырка в SSD образуется довольно быстро. ZRAM выгодно отличается от этого отсутствием лимита на циклы записи, так что даже если всеми забытый комп будет весь день свопиться в ZRAM - да и похрен. А если на SSD... эм...
> Это называется "систематическая ошибка выжившего".Просто те которые на 40 гиг могли быть с 2-level cell достаточно неубиваемым, а своп не сильно активно юзался. И все же не очень понятно зачем эмутировать оперативку достаточно тормозным способом. Ну ладно там ZRAM если поставить больше оперативы ну совсем не вариант.
Просто например у меня с 2010 года в одном массиве стояло две Тошибы на 60 гиг, и только одна выжила. :)
> Просто например у меня с 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 бита на ячейку не очень круглое число.
> Простой пример: у NAND прямо с фабрики в чипе defect list - и чип считается исправным, если в нем СРАЗУ С ФАБЫ "не более чем эн дефектов". SSD использует меньше полезной емкости чем суммарная емкость чипов, часть блоков зарезервирована на замену тех которые стали сбоить. Ну а как этот резерв заканчивается, фирмвара SSD и оказывается в патовой ситуации, как максимум в readonly выпадает. Потому что заменять дефектные блоки более не на что. Если теорвер так сложился что резерв быстро вылетел - ну, не повезло.Прямо как у HDD, надо заметить.
HDD отказывают как bath curve - но это немного отличатеся от флеша, в том смысле что у них нет отказов секторов за факт эн перезаписей. Магнитному слою пофиг 5 раз его переписали или 50 000, это не есть фактор для отказа. А у флеша вот именно циклы - разбалтывают электрические параметры ячейки и в конце концов перестает правильно уровни отличать.
Если систематическая, может и не ошибка вовсе?
У Вас есть шанс получить Нобелевскую премию по математике.
Не помню с каким ...SLC, ага.
Про 15 лет загнул конечно. Период в 8-10 лет более реалистичный.
10 лет массово, а 8 — уже очень массово. А так, если у кого были лишние 500$, тот и в 2008-2009 мог 128 Гб взять под систему и софт.
WMware WS хрен запустится без наличия своп-раздела.
Но у тебя все хорошо
Hibernate это вообще не про скорость загрузки.
Так давно уже отдельный раздел не нужен, можно в файл сбрасывать... ну, иногда. На некоторых дистрибутивах. На некоторые файловые системы. С некоторой комбинацией запущенного софта и установленного железа. С определенной вероятностью может даже сработать - у некоторых даже несколько раз подряд, но тут сам не видел и врать не буду.
В общем и правда - проще сказать, что "hibernate потерял актуальность".
Чото хайлоуд обмельчал каеш, кхем кхем, безусловно колличество запросов не мерило их ценности, но больше ста запросов в сек разве что для каких то супер задач хайлоуд, даж для фин транзакций нихуайлоуд
Тебе 15 лет, да? Или откуда такой идеализм?
Допустим у тебя есть нагруженый кластер Ceph на 10 стоек. Пару стоек моргнуло и запустилось снова. Начался resync, который жрет тучу памяти. Что по твоему лучше? Потормозить но синхронизоваться? Или лавинообразно сдохнуть от ООМ?
Такой вариант развития событий с памятью был в инциденте с Ceph у DO. Печально известный "мы старались, но у нас не получилось, проект закрыт" Cloudmouse, тоже сдох из-за недостатка памяти. Но там (для честности) помимо прочего еще и неадекватность присутствовала.
> Что по твоему лучше?По-моему надо было лучше планировать, вовремя закупать оборудование, настраивать OOM score, и другие кошерные вещи. Но если из вариантов только тормозить или умереть… Лучше умереть. Быстрее деньги на оборудование найдутся.
Твой подход не верный.Для примера реальный случай. Рендер в Blender на домашнем компьютере, который никогда для этого не использовался, да и был собран для другого. Память при рендере ушла в ноль, а далее был задействован swap. Работа выполнена, хоть и медленно. Раз в год и палка стреляет)
на десктопе очень неплохо работает zram. Тем более с нынешними процессорами и объемами памяти, когда тупо всякое ненужное у тебя пережимается и практически забываешь, что бывает oom
Чо, >200 запросов в секунду - это уже у наших любителей локалхоста highload?
У меня пых >1000 запросов в секунду на маленькой виртуалке делает.
Кстати, uksm годная штука, рекомендую. Особенно заметно на жава аппликухах, которые в ~2 раза меньше жрут. Процессора обычно достаточно, а вот без кешей хуже живётся.
для ksm над готовить всякие костыли вроде LD_PRELOAD оберток и прочего, изкаропки ток хипервизоры поддерживают
Uksm просто работает, периодически мержит одинаковые страницы фоном.
UKSM уже никем довольно давно не поддерживается. Давно столкнулись с архитектурными проблемами, патч вызывал проблемы со стабильностью и с эффективностью тоже были вопросы.
Какие проблемы со стабильностью и эффективностью, например? Я где-то пару лет использовал повсюду где можно. Патч можно и самому обновлять под апдейты (на гитхабе только под необновлённые ядра).
ну это примерно как с аллокатором: он тебе указатель таки отдаст, но память будет выделяться только когда попытаешься записать туда что-нить (и тут может быть ООМ)
Т.е. даже сейчас любой код, меняющий значение ячейки памяти (например X=5+3), может дать исключение ООМ? Это вообще в языках программирования нормально реализовано?
1) X=5+3 современный компилер скорее всего оформит как нечто типа mov r1, #8, посчитав еще в компилтайме.
2) При этом обращения в память скорее всего не будет вообще.
3) Если X далее не используется или это ни на что не влияет, то этого кода не будет вообще.
4) Если это было про возможность что array[10005000] = 10 упадет, вот тут уже возможны варианты. По дефолту в линухе оверкомит, а страницы памяти физически выделяются только когда начинают их реально использовать. И можно номинально заказать себе сильно больше формальной аллокации чем реально система могла обеспечить. Это не ведет к проблемам пока вы это все и сразу юзать не удумаете. Это отключаемо если так не нравится, это гарантирует семантику вещей типа malloc() yj неэффективно по использованию RAM.
> 3)?Отдуплившаяся страница помечается как CoW, как кто-то полезет
в неё на ЗАПИСЬ, она раздупляется и становиться самостоятельной.
>> 3)?Тоже самое, что и без дедупликации
Но сильно позже и с меньшими шансами, ибо память сэкономлена
Корректнее так:
1) Ну вот запустили мы кучу приложух через snap-flatpak
2) Запустили кучу приложух на электроне
3) Чё, нет денег на оперативу?
> В системном вызове open() запрещено одновременное указание флагов O_DIRECTORY и O_CREAT, которое теперь будет приводить к выводу ошибки EINVAL.*в тишине раздался кашель, сквозь который звучит что-то, напоминающее "we-never-break-userspace"*
Ну, юзерспейс и не сломан. Флаги на месте, код соберётся и будет работать. Единственное изменение, в данной комбинации флагов возвращается код с ошибкой, которую, теоретически, и так надо-бы было обрабатывать.
Вы правда думаете, что комментаторы с опеннета что-то пишут на сишечке или близко к ней? Тут же ржавый и гошланг правят бал. :)
Раст теперь потеряет свою безопастность.
Можно подумать, на rust и golang ошибки не надо обрабатывать.
Более того, там надо явно выразить желание НЕ обрабатывать :-)
Только на ней, увы, и пишут в подавляющем большинстве. На большее уже не способны.
Судя по комментам, тут только на assembler пишут. Ну ладно... Изредка на C, но НИКАКИХ плюсов!
Они хитрож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
. . .
А что, что-то сломалось?
> А что, что-то сломалось?Они ломают философию UNIX - "Всё есть файл!"
По-хорошему надо было сделать редирект на mkdir(), а тот бы уж вернул ENOTDIR,
если будут операции невозможные с директориями.
Какую философию?> 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.
И причём тут opendir() ?
Ты мне скажи. Это man 2 open.
> сделать редирект на mkdir()Ну и зачем там это связывание? Чтобы потом правка кода в mkdir() что-нибудь сломала, желательно втихую и с повреждением данных?
интересно, амуди когда-нибудь свой pstate доделает, что он уже по умолчанию будет?
SLOB, SLAB, SLUB... SLOB, SLAB, SLUB... йоу*читает рэпчик*
Опеннет 20ХХ год. Релиз ядра Linux 20ХХ. Было принято решение сменить нумерацию ядра на год выпуска соответствующего релиза. Весь код ядра был переписан с устаревшего и небезопасного языка С на безопасный ***. Напомним, что лицензия запрещает его называть, поэтому советом разработчиков ядра на всеобщем голосовании было принято решение дать этому языку кодовое имя ***. За проголосовало 99% представителей, один воздержался.
"В файловой системе Ext4 упрощена огранизация записи журнала (data=journal). Внесены оптимизации, связанные с предварительным распределением inode, позволившие ускорить работу в системах, в которых выполняется большое число случайных операций записи. Операции чтения и записи страниц памяти переведены на использование фолиантов страниц памяти (page folios)."А когда ожидается поддержка аттрибута "безопасное удаление", чтобы без shred обходиться? (сарказм)
> удалена опция монтирования "noacsrules", которая была некорректно реализована.ахаха, лучший багфикс эвер!
Чем теперь tmpfs+noswap будет отличаться от ramfs?
Тем что у ramfs фиксированный размер в памяти (сколько задали, не больше не меньше) и есть оверхед на форматирование.
не путайте ramfs с ram block device
вангую скоро выпилят ramfs
Неотключаемый selinux? А как же тогда гугловский Project Zero любым примитивом на запись его отключает? И почему с этим ничего не сделать?
Кто понял про этот LAM_57 режим? Могу ли я эти "лишние" биты использовать в своём user-space приложении например чтобы узнать, что помять не попорчена?
> Могу ли яhttps://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
>Добавлена поддержка предоставляемого в процессорах Intel режима LAM_U57 (Linear Address Masking), позволяющего использовать часть битов 64-разрядных указателей (c 57 по 62 биты) для хранения не связанных с адресацией метаданных.Ага. А потом "прекращена поддержка процессоров без LAM". Новые процессоры (а с ними и компьютеры целиком) себя сами не купят. Подобные вредительские инициативы нв корню рубить надо.
Фигасе далеко идущие выводы. Что там в ядре до сих пор поддерживается? i686?
1. не в ядре, а в прикладном софте. хотят хранить в указателях доп. инфу - могут использовать структуры struct fat_pointer {void * ptr; uint8_t bullshit[as_much_as_needed];}; и проверять их x86-кодом.
2. до ядра это тоже доберётся. i486 же дропнули. good riddance, как Линус сказал.
30+ летнюю архитектуру дропнули, как теперь жить.
Самое смешное, что стоны про то, что дропнули i486 раздаются от тех, кто в силу возраста или нищеты в 90ых не застал i486 вообще
А те кто застал совершенно плевать хотели на то, что дропнули процессоры, которые были 25 лет назад, ведь эти процессоры давно на помойке
Да и i686 давно пора дропнуть.
> slab SLABНасколько сейчас актуальны параметры командной строки ядра `slab_nomerge` и `slub_debug=FZ`?
>Одновременно латиноамериканский Фонд свободного ПО сформировал вариант полностью свободного ядра 6.4 - Linux-libre 6.4-gnu, очищенного от элементов прошивок и драйверов, содержащих несвободные компоненты или участки кода, область применения которых ограничена производителемПриятно видеть как наши товарищи из Латинской Америки сохраняют революционную сознательность.
Вот бы ещё весь хлам выпиливали
> Добавлена поддержка предоставляемого в процессорах Intel режима LAM_U57 (Linear Address Masking), позволяющего использовать часть битов 64-разрядных указателей (c 57 по 62 биты) для хранения не связанных с адресацией метаданных. Для обычных программ не требуется столько памяти,1) "640кб хватит всем"
2) хак завязанный на особенности реализации и поведения железа.
3) Дремучее legacy родилось на наших глазах.
>> (c 57 по 62 биты) для хранения не связанных с адресацией метаданных. Для обычных программ не требуется столько памяти,
> 1) "640кб хватит всем"С одной стороны да, но 2^57 = 144 петабайта, если я не ошибся. Ограничения в 144 петабайт ОЗУ, при том, что в микроэлектронике мы уже уперлись в серьезные ограничения по размеру элементов, их соединений и, соответственно, их плотности упаковки и теплоотдачи, наверное лет на двадцать хватит минимум. Разве что изобретут что-то революционное, принципиально отличное от существующих технологий.
>> лет на двадцать хватит минимумСрок реально небольшой, чтобы каку зарывать
Intel бы с радостью и на год каку зарыла. Новые камни сами собой не купятся.
>>> (c 57 по 62 биты) для хранения не связанных с адресацией метаданных. Для обычных программ не требуется столько памяти,
>> 1) "640кб хватит всем"
> С одной стороны да, но 2^57 = 144 петабайта, если я не
> ошибся. Ограничения в 144 петабайт ОЗУ,не "ОЗУ", а в аппаратной адресации. Это большая разница.
Мало тебе MemoryHole 640кб-1Mb, 15-16M, теперь и это добавили.
> при том, что в микроэлектронике
> мы уже уперлись в серьезные ограничения по размеру элементов, их соединений
> и, соответственно, их плотности упаковки и теплоотдачи, наверное лет на двадцать
> хватит минимум. Разве что изобретут что-то революционное, принципиально отличное от существующих
> технологий.https://i.pinimg.com/originals/d1/f1/db/d1f1db3ec965a65f5c16...
> не "ОЗУ", а в аппаратной адресации. Это большая разница.Ты хочешь сказать, что при 144-петабайтной адресации надо учитывать объем легаси-дыр? Ты хочешь сказать, что все эти твои дыры из адресации сожрут 143 пертабайта и на "реальную ОЗУ" у тебя останется жалкий петабайт? Думаю, согласишься, что нет.
Так что этими дырами можно пренебречь и повторить утверждение, что 144 петабайт озу это дофига и даже наверное недостижимо при существующих и "ближнебудущных" технологиях - частоты, предельные размеры элементов (даже когда перейдем на маркетинговые "2нм" года через 3-5). Да и разносить элементы далеко друг от друга ты сможешь только в ущерб скорости - скорость света же ограничена. Например, при тактовой частоте в 3 ГГц за один такт электромагнитная волна может пройти всего 10 сантиметров. Удачи тебе собрать ОЗУ на 100 петабайт по технологии "2 нм", скомпоновать всё это настолько компактно, чтобы можно было бы хотя бы, условно, на 1 ГГц с ней работать, а потом еще, с такой черепашьей скоростью, попробуй по полной загрузить это ОЗУ данными и работать со всеми 100 петабайтами.
> https://i.pinimg.com/originals/d1/f1/db/d1f1db3ec965a65f5c16...Не совсем понятно к чему это. А теперь давай хотя бы 10 петабайт (124 петабайта адресации оставим на дыры) вот такой памяти как на этой фотке. Интересно, планеты тебе хватит? Если ты пытался намекнуть "что было вот, а стало - вот, так что не бойся, так будет и дальше" - огорчу - технологии уже уперлись в пределы, где размеры элементов или их компонентов уже десятками атомов считаются. Дальше уменьшать уже сложно - там всякие квантовые, туннельные эффекты и прочее г.вно, уже проявляются значительно сильнее и система становится крайне нестабильной.
>> не "ОЗУ", а в аппаратной адресации. Это большая разница.
> Ты хочешь сказать, что при 144-петабайтной адресации надо учитывать объем легаси-дыр?я прямо говорю что при любой адресации, любая дыра это не есть хорошо.
сколько десятилетий "аукались" те дыры, даже уже после выхода десятков поколений нового железа?легаси.
суровое наследие, поддерживаемое для совместимости.
> - скорость света же
> ограничена. Например, при тактовой частоте в 3 ГГц за один такт
> электромагнитная волна может пройти всего 10 сантиметров.8 см. скорость света зависит от среды. в плотной среде - медленнее. для электромагнитных волн есть среды замедляющие их скорость в сотни раз.
пока шина процессора работает на сотнях мегагерц, этой разницей можно пренебречь.
Но если ты взглянешь на материнскую плату своего компьютера, то увидишь что некоторые дорожки выполнены змейкой - специально удлинены, чтобы сигнал по ним приходил одновременно с сигналом по другой, прямой дорожке.
> компактно, чтобы можно было бы хотя бы, условно, на 1 ГГцуже есть терагерцовая электроника. прямо сегодня для богатых заказчиков. через короткое время будет в продаже на массовом рынке.
> попробуй по полной загрузить это ОЗУ данными и работать со всеми 100
> петабайтами.сериализовать Большую Советскую Энциклопедию на JS, и придется еще свапится.
>> https://i.pinimg.com/originals/d1/f1/db/d1f1db3ec965a65f5c16...
> Не совсем понятно к чему это.это говорит о твоем узком кругозоре.
> технологии уже уперлись в
> пределы, где размеры элементов или их компонентов уже десятками атомов считаются.ты можешь пользоваться только тем, что придумал кто-то другой и заставил тебя пользоваться,
все иные варианты ты не способен вообразить.
по этому с тобой скучно.
фотография сделана в то время, когда такие как ты, говорили что сделать больше 16 килобайт в компактном размере невозможно.
человек на фото запихнул в равный объем 4 мегабайта, решив проблемы питания охлаждения и др.всегда найдется тот, кто сделает сегодня то, что ты считаешь невозможным даже завтра.
> я прямо говорю что при любой адресации, любая дыра это не есть хорошо.Ну, поставить атрибуты в MMU и дело с концом. Он эксепшн кинет, какое ему дело. Ну и юзерский софт работает с виртуальными адресами же, физические, с дыркой, только ядро и видит.
> уже есть терагерцовая электроника.
Ну так на допустим 10-40ГГц сто лет как есть для спутниковых коммуникаций и микроволновых линков. Не означает что проц на такой частоте будет работать. Там основной лимит это нагрев вообще, слишком быстрая схема с вольтажом потребным для стабильной работы на этой скорости на данном техпроцессе - тупо перегревается. В это все и упирается. Ну а на 10ГГц реально загнать только какой-то относительно примитивный чип с небольшим числом элементов, соответственно. А миллиарды транзисторов переключать на таких частотах - вопрос в энергии на переключение и количестве.
> сериализовать Большую Советскую Энциклопедию на JS, и придется еще свапится.
Сейчас базы и сильно поболее этого. Да и зачем при сериализации гигазы рамы?
> через короткое время будет в продаже на массовом рынке.
Этой прохладной истории уже более десятка лет, между прочм.
> всегда найдется тот, кто сделает сегодня то, что ты считаешь невозможным даже завтра.
А можно мне уже нормальных источников энергии? Ну вот задолбали батарейки сделаные человечеством, самый негодный аспект развития человечества пока. Каждый год обещают что вот вот станет ЗБС. И такая хрень уже более 20 лет для одного только лития. А реально вон там лопатники которые в карман не лезут состоящие из по сути батарейки, и даже так в обнимку с паварбанком - иначе за день выдыхается.
В последнее время nvme под систему хватает с избытком, поэтому и swap = 2x ram и 30% не размечаю. И выполняю заветы олдов, без понимания. И комментарии как то ясности не добавили. Есть новый завет?
Если используете гибернацию, размер подкачки желателен не меньше ОЗУ (хотя нередко достаточно столько, сколько ОЗУ занято). Если не используете, посмотрите, сколько в подкачке по максимуму бывает, из этого исходите. Если вдруг сильно понадобится подкачка, на популярных ФС её можно добавить, создав ещё файл. Про резерв 30% не знаю, что и сказать - производитель и без этого предусмотрел резерв. Экспертами платят торговцы железом, так что надо стимулировать спрос.
Однажды изучив технологию ssd, всю жизнь имели бы на 30% больше дискового пространства.
> возможность создания работающих на уровне ядра обработчиков (kernel worker) из процессов в пространстве пользователя. (...) Реализация оптимизирована для совместного использования с io_uring.Раздолье-то какое, раздолье!
> возможность создания работающих на уровне ядра обработчиков (kernel worker) из процессов в пространстве пользователяастрологи объявили неделю LPE уязвимостей
> В интерфейсе асинхронного ввода/вывода io_uring появилась возможность одновременной прямой записи в файл в несколько потоковА диск такой: "В очередь, с*кины дети, в очередь!".
Чем-то напоминает "менеджеры загрузок" эпохи диалапа, когда хомячки верили, что скачивание файла в несколько потоков позволит преодолеть лимит скорости модема.
Походе, ни о временах диалапа, ни о нынешних накопителях вы ничего не знаете.
Если Вас так задели мои слова, у вас есть шанс блеснуть познаниями по части менеджеров загрузки и современных накопителях.
Позволяло если админ на той стороне ставил ограничение на скорость отдачи ниже лимита скорости модема. Проверено лично и неоднократно.
Вообще говоря, оно и сейчас много где актуально.
еще помогало, если линия не очень хорошая и часто возникали ошибки передачи. Пока один поток перезапрашивает кусок, файла линия простаивает, и второй в это время спокойно качает свою часть.
Так этож преодоление ограничений отдающего, а не ограничения скорости собственного модема.
В эпоху диалапа не каждый браузер знал про Accept-Ranges, и докачка (после обрыва соединения) работала в основном в менеджерах.
Вас уже обваляли в фикалиях по части диалапа. Бодбодрю жижу, в которой плескаетесь, со своей стороны:
для файла, занимающего страницы (по 4K), относящиеся к различным блокам страниц (~по 128 страниц) на диске, современный контроллер без сложностей обеспечит асинхронную параллельную запись.
Здесь нашлось несколько индивидов, которые любят набрать в рот фекалий, чтобы плюнуть в сторону оппонента. На это забавно смотреть со стороны, особенно, когда к процессу присоединяются новые участники.
И не говорите. Ещё забавней наблюдать, как Вы в этих фикалиях плескаетесь, будучи не способным на контраргументацию, а лишь продолжая множить свои заблуждения.
Да что ж Вам всё неймётся-то? Всё плюётесь и плюётесь...
Пока Вы так прелестно плескаетесь, хочется только подливать.
У скачивания файла в несколько потоков с быстрых серверов по диалапу было и есть вполне себе резонное объяснение.
К любимому мной 2G ныне всё настолько же применимо.
Дело кроется в регулярных потерях пакетов на сверхмедленном канале, а особенно - tcp ack, при приличном значении roundtrip latency.
Дальше объяснять не буду.
Молодцы корпорации. Хорошо потрудились.
да... и любой сможет этим пользоваться...
Я и говорю - молодцы. Должен же кто-то и само опенсорсие писать хотя бы ради прикола, а не 4 свободы и прочие лозунги.
Не потрудились, а оплатили. И оплатили строго говоря тоже не корпорации, а их клиенты. Корпорация - посредник и паразит.
из всего я не понял - btrfs raid 5/6 уже можно или еще рано?
Если бы в самом деле хотели понять, то обратились бы к документации на kernel.org.
Как и ранее, для данных можно, для метаданных не рекомендуется. Для метаданных следует применять raid1, raid10, raid1c3, raid1c4. Для последних двух формат хранения ещё не зафиксирован.
спасибо тебе, язвительный чел. обо всем этом я знаю.
Может знаешь, а может и нет. Правда неизвестна, есть только твой вопрос в начале ветки и отписка на мой ответ.
> Для последних двух формат хранения ещё не зафиксирован.Это с чего это не зафиксирован? Никто это уже ломать не собирается, вы чего. Из изменений V2 формата там скорее множественные экстентные деревья хотели и т.п. - сейчас в массово параллельной нагрузке с 1 деревом - lock contention случается, неоптимально по скорости, актуально для суперскоростных энтерпрайзных SSD.
Ломать может и не собираются, но формат raid1c3 и raid1c4 остаётся не зафиксированным.
> Ломать может и не собираются, но формат raid1c3 и raid1c4 остаётся не > зафиксированным.Где это написано?
Давно можно. Метаданные хранишь на RAID1 (Подойдут 1TB диски, которые можно купить за копейки), а данные на RAID5/6. Все работает как часы.
Для какого размера массива данных Вы предлагаете 1 Тбайт под метаданные?
1 к 20-25 примерно. Зависит от выбранного алгоритма чексумм и от самих данных. Если очень много файлов маленького размера - они могут храниться в метаданных.
Вы дикость пишите. Для записи 1 Тбайт данных потребуется от силы 4 Гбайт метаданных, что есть 0.4%. Но никак ни 4-5% как утверждаете Вы.
Чукча не читатель, чукча писатель?Btrfs данные маленьких файлов может хранить в метаданных. Мануалы кури, чукча.
> Для какого размера массива данных Вы предлагаете 1 Тбайт под метаданные?Вы явно не понимаете как RAID5/6 работает вообще - и тем более "file based" btrfs инкарнация в частности. Иначе не понятно откуда реверанс про терабайт под метаданные. Btrfs аллоцирует чанки данных и метаданных юнитами порядка нескольких гигз, блочные группы для данных или метаданных, в том или ином формате. Сколько ему будет надо под метаданные - столько и аллоцирует, если это место вообще было.
Откуда тут терабайт на метаданные берется в хоть каких-то факторах - кто ж его знает.
RAID5 с метаданными в RAID1 - почему нет? У RAID6 write hole пока еще есть, до конца еще не заткнута. Другое дело что вон то сделано недавно, оттестированость пока еще скромная.
Зачем писать код ядра на Rust, когда его можно писать на BPF?
> Из ветки 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.
> добавление всей этой кампании ключей 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
> А патч для очистки Linux от ржавчины где?А оно опциональное при сборке. И там вроде пока даже и очищать особо нечего.
> Предполагаю что всё это затеяно для исключения GRUB. Другие загрузчики не поддерживают
> загрузку с шифрованных разделов и верификацией загрузки модулей, настроек, ядра и
> initrd.Не поддерживают {загрузку с шифрованных + верификацию}, или только первое? Для корня в LUKS поддержки загрузчиком вроде никакой не нужно
>В драйвере AMD IOMMU (amd_iommu) появилась поддержка 5-уровневых таблиц страниц памяти, что позволяет выделять до 4 ПБ физической памяти гостевым системам.Это проверенная информация или на верочку?
А потом ВРЕЗАПНО выяснится, что после 2 с чем-то лет оно перезагрузится
