В кодовую базу, на основе которой формируется ядро Linux 6.5, принято изменение с реализацией нового системного вызова "cachestat", позволяющего программам в пространстве пользователя запрашивать более детальную статистику из страничного кэша на стороне ядра...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=59435
вот на слух похоже на реально нужную штуку.
ну а если включить обывателя: по больше бы подобных вещей разрабатывали, а не всякие *сты для *стов в ядро внедряли!!!
каждая такая штука означает расходование процессорного времени и ресурсов.
Причем острой необходимости в таких штуках как правило нет. Это примерно как ходить круглый год всегда и везде в валенках и с зонтиком. И душ принимать не снимая валенок...
> каждая такая штука означает расходование процессорного времени и ресурсов.Если не пользоваться такой штукой, то нет никакого расходования процессорного времени и ресурсов. А если её не собирать при компиляции, то и в памяти она не висит.
В системе для разработчика оно надо и будет работать, во встройщине её даже компилить не обязательно. Так работает линукс, чувак.
Вижу, ты до конца статью не дочитал...
Посмотри, какие там они примеры использования предлагают. Это никак не для разработчиков.
А штука тежеленная получиться. Потом ее будут годами оптимизировать и баги с утечкой информации фиксить.
>> расходование процессорного времени и ресурсовТак может пора уже слезть со своего православного 775 сокета? На современном железе это из разряда экономии на спичках, разница будет в пределах тысячных долей процента.
кажись вы не знаете о чем говорите
Ядро винды не обновляли n-цать лет и оно по прежнему работает идеально.
а command.com вдруг перестал работать?
Не сижу на этом сайте, мне всё равно
> Ядро винды не обновляли n-цать лет и оно по прежнему работает идеально.https://ru.wikipedia.org/wiki/Windows_Display_Driver_Model
Windows Display Driver Model (WDDM, также WVDDM в эпоху Vista) — это архитектура графических драйверов для видеокарты под управлением Microsoft Windows, начиная с Windows Vista
- Windows 7 поддерживает WDDM 1.1;
- Windows 8 включает WDDM 1.2;
- Windows 8.1 включает WDDM 1.3;
- Windows 10 включает WDDM 2.0;
- Windows 10 Anniversary Update (версия 1607) включает WDDM 2.1;
- Windows 10 Creators Update (версия 1703) включает WDDM 2.2;
- Windows 10 Fall Creators Update (версия 1709) включает WDDM 2.3;
- Windows 10 April 2018 Update (версия 1803) включает WDDM 2.4;
- Windows 10 October 2018 Update (версия 1809) включает в себя поддержку WDDM 2.5;
- Windows 10 May 2019 Update (версия 1903/1909) добавляет поддержку WDDM 2.6;
- Windows 10 May 2020 Update (версия 2004) привносит поддержку WDDM 2.7;
- Первая финальная версия Windows 11 RTM (версия 21H2) включает поддержку WDDM 3.0;
- Windows 11 версии 22H2 включает поддержку WDDM 3.1;
- Тестовые сборки Windows 11 Insider Preview 25xxx (версия 23H2) включают WDDM 3.2
> Windows Display Driver Model (WDDM, также WVDDM в эпоху Vista) — это
> архитектура графических драйверов для видеокарты под управлением Microsoft Windows,
> начиная с Windows VistaА файлуха как была тормозом с 90х так и осталась. Поэтому если попробовать ворочать иерархией с 200К файлов как я это в линухе делаю у вас - там одна сплошная "виндус виста", что так что сяк. И вон тот проект в лине билдуется в разы быстрей. Никакие видеодрова этому не помогут.
> каждая такая штука означает расходование процессорного времени и ресурсов.Не факт. Оно внутрях могло знать больше чем вывешивало наружу, для принятия внутренних решений и проч. А интерфейса наружу могло и не быть.
Ну и линуксоиды сейчас в лидерах по IOPS на ядро и все такое. Хотите поучить их делать это правильно - делом покажите что можете лучше.
> Причем острой необходимости в таких штуках как правило нет.
Намного лучше тыкаться везде как слепому котенку не имея данных о перфомансе системы и затыках.
Да что говорить
Элементарно загруженность шин посмотреть нельзя,да блин lsi чип хз когда виновник тупняка....все по каким-то левым догадкам
Хотели бы как лучше, а получится скорее всего очередная дыра для утечек по сторонним каналам
Вот ты нытик тоже.
Но капитан же?
То есть СУБД будет принимать на основе cachestat решения, которые будут влиять на cachestat. Страничный кеш адаптируется к поведению программы, а теперь и программа будет адаптироваться к состоянию кеша, можем получить положительную обратную связь, так что пользоваться этим нужно очень осторожно.
Это стандартная проблема, ей сто лет в обед. Решается так же стандартно - адаптироваться не моментально, а постепенно, чтобы "волны" затухали.
Всё равно будет иногда попадать в резонанс.
Можно рандома ещё добавить
путем отключения этой хрени
Вот сделали cachestat, все закэшировано, в следующую наносекунду другой файл запросили, все выгрузилось из кэша, а бд уже решила читать файл без индекса, не зная что его не в кэше.
Как это должно работать? Вероятностно (в надежде что никто кэш активно не вытесняет/вдруг повезёт?)?
Да, в среднем будет работать на x% быстрее. Как те же хардварные префетчеры, например
А прогрев епта кто будет делать?
Не знаю как прогревать "епта" но вообще, софт может и префетчить нужное. И это ессно без статистики не получится нормально делать. Чтобы оптимизить поведение софта - надо знать что уже есть и в правильную ли сторону движение.
> И это ессно без статистики не получится нормально делать.Так статистика это и есть прогрев
> Да, в среднем будет работать наx быстрее.Fixed.
Хороший вопрос - мне кажется что вероятностно, но вероятностно оно и сейчас так у того же постгреса - есть коэффициенты на случайный и линейный доступ и есть внутри надежда что данные в page cache. У мускуля менее вероятностный при включенном directio - уповает на собственный buffer pool.
>У мускуляСтарый мускуль с отрубленным кверикешем быстрее работает при высоком кешмиссрейте, и жутко, жутко тормозит с включенным :)
>>У мускуля
> Старый мускуль с отрубленным кверикешем быстрее работает при высоком кешмиссрейте, и жутко,
> жутко тормозит с включенным :)Query cache это другое, но ок, у старого мускуля ещё и завязки на myisam/vfs, чтоб хоть как-то можно было привязать к теме.
Вывод: пользы 0
В старом мускуле причина тормозов в giant lock на query cache.
> В старом мускуле причина тормозов в giant lock на query cache.угу
> в следующую наносекунду другой файл запросили, все выгрузилось из кэшаТакая ситуация возможна только при жёстком OOM, когда всем уже пофиг на твои проблемы с cachestat. В обычной ситуации так не бывает.
> В обычной ситуации так не бывает.:)))))))))) 99% ситуаций это на грани ООМ
> Гранулированное и зависимое от нагрузки манипулирование наполнением и вводом-выводом страничного кэша (например "грязных" (dirty) страниц/страниц, помеченных на отложенную запись (writeback)), меняя частоту синхронизации - от очень частой при слабой нагрузке и до пакетной при всплесках нагрузки.Т.е.?
Компьютер быстрее работать будет
Ага, вспоминаются заставки во премя установки винды. Когда каждая новая "быстрее, выше, сильнее", а на деле прожорливее и тормозее. Если на моем 486DX прекрасно летала 95 винда, то 98 уже свопилась и прилично тормозила, причем в тех же программах.
Количество системных вызовов стремительно приближается к количеству функций WinAPI. Что-то с этим не так, какая-то проблема в архитектуре ОС.
Сравнение, имхо, некорректно. В WinAPI это то, что находится в kernel32.dll, advapi32.dll, user32.dll и gdi32.dll. Т.е. там много всего, вообще не относящегося к ядру ОС, разные там MultiByteToWideChar(), ZeroMemory() и прочее, то, что у Unix-систем располагается в libc. И, соответственно, к числу этих функций количество системных вызовов стремительно приблизиться никак не может. А системных вызовов, наверное, уже примерно столько-же, плюс-минус, сколько системных вызовов в ОС Windows.
надо пасьянс Косынка сделать системным вызовом...
> надо пасьянс Косынка сделать системным вызовом...погоду делать надо :) и одним системным вызовом она не испортится
Ну так куда без libc, можно сказать что ядро))). Всё так же приколочено.
Молодцы. Обратная связь в процессе управления — важнейшая вещь.
"Си-библиотека Cosmopolitan..." только что решила, что она портабельная и тут опять :)))