Какой патч? Зачем? Чтобы glibc делало что?
Чтобы elf-загрузчик ld-linux.so (который, собственно, идет вместе с libc) mmap-ил elf-ы с флагом MAP_LOCKED.
Alexander
Чтобы elf-загрузчик ld-linux.so (который, собственно, идет вместе с libc) mmap-ил elf-ы с флагом MAP_LOCKED.
так уже есть memlockd, который примерно так и делает
Однако memlockd не делает ничего автоматически, нужно самостоятельно искать подходящие файлы и вставлять в конф.
Alexander
так уже есть memlockd, который примерно так и делает
Не совсем то же: memlockd просто лочит файлы по стаическому списку, причем, не особо разбираясь, какого типа файл лочится. Плюс, сам подход костыльный: вместо того, чтобы тип отображения выбирал тот, кто отображение создает, запускается какая-то стороння штука, которая пытается косвенно добиться похожего результата.
Vasiliy Glazov
Кстати, никто не знает, когда у нас Thunderbird обновят?
Так, вроде, последняя версия в репах.
Soul Catcher ☮️
http://www.opennet.ru/opennews/art.shtml?num=47100
Ура, наконец дожили. Событие потрясающие. Единственное, почему приходилось переключаться в иксы, это скринкаст. Всё, можно сидеть на вяленом 25/7
Александр
Хз постили или нет https://itsfoss.com/btrfs-default-fedora/
артем
Чтобы elf-загрузчик ld-linux.so (который, собственно, идет вместе с libc) mmap-ил elf-ы с флагом MAP_LOCKED.
Немного не в тему, но в Android закрепление файлов в памяти делает как раз сторонний процесс, не связанный с линкером
артем
да и реализация этой штуки в линкере выглядит как костыль
Alexander
Немного не в тему, но в Android закрепление файлов в памяти делает как раз сторонний процесс, не связанный с линкером
С архитектурой андроида не очень знаком. А что за компонент на андроиде лочит отображения elf-ов?
Alexander
да и реализация этой штуки в линкере выглядит как костыль
Если говорить про glibc, то в линкере надо всего лишь добавить параметр MAP_LOCKED в вызов mmap-а. Куда уж менее костыльно? Вся вся работа загрузчика и заключается в том, чтобы подготовить память для программы. Довольно странно считать, что один из мелких нюансов всего процесса подготовки требует отдельного демона с эвристикой для получения информации, которая у загрузчика есть по определению.
Alexander
@okhttp вообще, судя по исходниками linker-а в bionic, память он аллоцирует и загружает эльф вполне себе сам.
https://github.com/aosp-mirror/platform_bionic/blob/29cff99e08746f8060f32eba03df3b95acf1163d/linker/linker_phdr.cpp
См. метод ElfReader::Load и всё, что он вызывает.
артем
С архитектурой андроида не очень знаком. А что за компонент на андроиде лочит отображения elf-ов?
По своей сути весь GUI представляет собой java-часть, и поэтому программы производится с помощью fork(), запуск ELF в общем случае происходит только во время загрузки ОС. За блокировку файлов отвечает PinnerService, который по-умному блокирует как файлы приложения, так и файлы из захардкоженного списка.
артем
А добавление эвристики в системную библиотеку звучит не очень надёжно
Alexander
По своей сути весь GUI представляет собой java-часть, и поэтому программы производится с помощью fork(), запуск ELF в общем случае происходит только во время загрузки ОС. За блокировку файлов отвечает PinnerService, который по-умному блокирует как файлы приложения, так и файлы из захардкоженного списка.
А, ну так это используется как часть подхода, когда любое приложение может быть выгружено системой в произвольный момент времени. В LSB-системах ситуация несколько иная.
Alexander
Но тогда блокируются все программы
Во-первых, управление таким поведением (как это уже сделается с другими аспектам работы загрузчика) можно организовать через переменную окружения
Alexander
Во-вторых, то, что будут лочиться все elf-ы, в большинстве систем проблем вызвать не должно.
Alexander
А те, кому нужно задавать индивидуальные параметры, смогут сделать это через переменную окружения
Alexander
Можно также заморочиться и сделать механизм с конфигами на манер ld.so.conf, если нужна ещё большая гибкость и удобство (но мне это уже кажется излишним).
артем
Во-вторых, то, что будут лочиться все elf-ы, в большинстве систем проблем вызвать не должно.
Что делать если elf условно большой? Получается, что нужно было бы заранее знать про такую особенность glibc и поставить переменную окружения. А если наоборот, по умолчанию ничего не пинить, то мы приходим к тому же memlockd, но вшитому в линкер
артем
Можно также заморочиться и сделать механизм с конфигами на манер ld.so.conf, если нужна ещё большая гибкость и удобство (но мне это уже кажется излишним).
Мне кажется, что все проблемы с данным механизмом будут очень медленно решаться
артем
Как и всё связанное с libc
артем
На просторах интернета читал про неудачную попытку улучшения реализации hashmap, которую просто проигнорировали
артем
Привет спискам рассылок и консервативному методу разработки
Alexander
Что делать если elf условно большой? Получается, что нужно было бы заранее знать про такую особенность glibc и поставить переменную окружения. А если наоборот, по умолчанию ничего не пинить, то мы приходим к тому же memlockd, но вшитому в линкер
На десктопах таких бинарей обычно не бывает. А те, кто создают элфы на сотни мегабайт-гигабайты, обычно уже в курсе что да как (и не факт, что они отключат лок страниц в загрузчике).
артем
Alexander
AppImage всякие, нет?
Ок, appimage-и - это аргумент. В таком случае можно сделать отсечку по размеру файла (ну и параметризировать лимит для неё)
артем
Когда подобная оптимизация реализуется на низком уровне, то любые проблемы с ней можно аргументировать как "сам дурак"
артем
А демон можно и поругать
артем
И пофиксить если надо
артем
Ок, appimage-и - это аргумент. В таком случае можно сделать отсечку по размеру файла (ну и параметризировать лимит для неё)
Получается, что уже придумываем критерии
Alexander
Когда подобная оптимизация реализуется на низком уровне, то любые проблемы с ней можно аргументировать как "сам дурак"
Это какое-то очень обобщение суждение, и при этом я не вижу его связи с реальностью.
Alexander
Получается, что уже придумываем критерии
Конечно, придумываем. Если поднимать лапки и бежать лепить костыли при любом возникающем вопросе относительно решения, мир был бы намного хуже.
артем
Это какое-то очень обобщение суждение, и при этом я не вижу его связи с реальностью.
Ну при разработке ядра всегда придерживаются принципа, что юзерспейс всегда прав. Даже если программа делает глупость, апдейт ядра никак не должен повлиять на это
артем
А glibc чем хуже? Такой же основной компонент системы
артем
Почему при его обновлении что-то должно ускориться, а что-то замедлиться и/или уйти в ООМ
Alexander
Почему при его обновлении что-то должно ускориться, а что-то замедлиться и/или уйти в ООМ
Лок elf-ов слабо повлияет на наступление oom. Большую часть памяти занимают данные.
артем
В общем случае да, но если притянуть за уши, то можно придумать workload, где это не так
Alexander
А glibc чем хуже? Такой же основной компонент системы
Но это же не значит, что вообще ничего нельзя менять, ведь любое изменение в коде приводит к изменению поведения.
Alexander
Alexander
Причём такой, который при этом не сломается, если лочить память будет демон.
артем
Но это же не значит, что вообще ничего нельзя менять, ведь любое изменение в коде приводит к изменению поведения.
Если поиск в массиве работает за O(n^2), а его оптимизировали до O(n), то результат не изменился, хотя всё и ускорилось
артем
Нарушения контрактов чинить нужно ещё
артем
Причём такой, который при этом не сломается, если лочить память будет демон.
Демон можно будет легко взять и обновить!
артем
А обновление либц требует перезапуска
артем
Если не ошибаюсь
Alexander
Если поиск в массиве работает за O(n^2), а его оптимизировали до O(n), то результат не изменился, хотя всё и ускорилось
Ты не поверишь, но это может может что-нибудь сломать, особенно в многопоточных программах :)
артем
Ты не поверишь, но это может может что-нибудь сломать, особенно в многопоточных программах :)
Безусловно, но я подразумевал последовательное выполнение
артем
Без фокусов
Alexander
А обновление либц требует перезапуска
Это изменение наибольшее влияние оказывает либо в период запуска, либо при oom. Если программа уже запустилась, то первое нас уже не очень волнует, а если наступил oom, то всё равно перезапуска.
Alexander
Безусловно, но я подразумевал последовательное выполнение
В смысле? Что это за сферический пример в вакууме? Мы говорим про библиотечный код, и ты не можешь запрещать юзерам использовать его в любых условиях.
Anonymous
Я уже спрашивал, но внятного ответа не получил. Есть Bluetooth мышь, настроенная на подключение к ноуту M590. Ноут на ночь выключается, если включать утром, то мышь иногда не подключается. Помогает зайти в настройки Bluetooth и в ручную понажимать кнопку соединения
артем
Это изменение наибольшее влияние оказывает либо в период запуска, либо при oom. Если программа уже запустилась, то первое нас уже не очень волнует, а если наступил oom, то всё равно перезапуска.
Если я правильно понял, то MAP_LOCKED не даёт Kswapd произвести eviction региона
Alexander
Сейчас ничего в голову не приходит кроме банальных примеров :)
Значит решение уже относительно неплохое :)
При речью нужно исходить из более-менее реалистнчных проблем. Потому что, если исходить из посылок "а вдруг произойдёт что-то плохое, но я пока не знаю что", то так можно рубить любые инженерные решения.
артем
Если я правильно понял, то MAP_LOCKED не даёт Kswapd произвести eviction региона
А это приведёт к фризам
артем
Потому что дольше придётся искать, что выкинуть
Alexander
Лок elf-ов слабо повлияет на наступление oom. Большую часть памяти занимают данные.
Сильно влияет. Выше смотри видео.
артем
Да, примерно так.
Значит, тяжёлый процесс, который уснул сильно и надолго, мы не можем выкинуть
артем
Хоть он и LRU
Alexander
Значит, тяжёлый процесс, который уснул сильно и надолго, мы не можем выкинуть
И насколько большими должны быть его исполняемый файл и библиотеки?
артем
И насколько большими должны быть его исполняемый файл и библиотеки?
Пускай памяти у нас 512 МБ, а таких процессов либо несколько, либо много, и они поменьше
артем
Какой-нибудь SailfishOS
артем
Для смартфонов
артем
Они тоже используют glibc и хотят блокировать память
На деб10 lxde весь гуй весит 80м. На гноме 500м
Alexander
Для смартфонов
Разработчики ос для смартфонов уже взрослые мальчики и при разработке собственной ос (а там задача даже не собрать дистр из готового софта) как-нибудь уж с параметрами системы разберутся.
Alexander
Сделают вытеснить как на андроиде, например.