Мениджърът на паметта е подмножество на системата експлоатационен Той споделя памет между операционната система и различните приложения. Терминът памет се отнася главно до основната памет (RAM), но нейното управление изисква приноса на спомагателната памет и кеш паметта.
Мениджърът на паметта е особено отговорен за ефективно разпределяне на паметта към процесите, което означава, че трябва да можете да изброите свободните местоположения на наличната памет, да разпределите паметта, необходима за нови процеси, и да възстановите паметта от процеси, които се прекратяват. Диспечерът на процеси в ядрото на Linux е диспечерът на SLAB.
ПЛОЧА разчита на блок и кеш система, която оптимизира заявките за памет. Този тип управление на паметта намалява фрагментацията, причинена от операции по разпределение и преместване.
Разпределението на блокове включва внедряване на кеш за определен тип / размер на обект, който има няколко предварително разпределени блока памет, нарязани на парчета с фиксиран размер, които са подходящи за конкретни обекти.
SLAB управлява парчетата, така че когато се изисква ядрото да разпредели памет към обект, Можете да задоволите тази заявка с резервна част от съществуващ блок. SLAB запазва разпределената памет за повторно използване при последващи разпределения на подобни обекти и по този начин намалява режийните разходи, свързани с инициализацията на обекта.
Те възнамеряват да заменят SLAB
Роман Гущин, Член на инженерния екип на ядрото на Linux във Facebook, той откри това, което вижда като „сериозен недостатък“ в текущия мениджър / контролер на паметта. И rнаскоро предложи нов контролер на паметта блок което обещава драстично да подобри използването на паметта сред множество "cgroups" (или контролни групи) от паметта.
Като се има предвид това, важно е да се отбележи, че cgroups се отнася до характеристика на ядрото на Linux, която позволява ограничаване, броене и изолиране на използването на системни ресурси (процесор, памет, използване на диска и т.н.) и термина "страница на плоча" може да бъде асимилиран към процеса на разпределение на паметта от SLAB.
Според Гущин:
„Истинската причина, поради която съществуващият дизайн води до ниско използване на SLAB, е проста: страниците с плочи се използват изключително от един пул памет.
Ако има само няколко разпределения с определен размер, направени от cgroup или ако има някои активни обекти, останали след премахването на cgroup, или ако cgroup съдържа едно приложение с резба, което на практика не разпределя ядра, но го прави всеки път в нов процесор: Във всички тези случаи получената употреба на SLAB е много ниска.
Ако изчисляването на kmem е деактивирано, ядрото може да използва свободно място на страниците на плочки за други разпределения «.
Gushchin твърди, че това не е било проблем, когато драйверът на kmem е въведен като незадължителна функция, която трябва да бъде активирана за всеки пул памет.
Сега обаче, драйверът на kmem е активиран по подразбиране за cgroup v1 и v2. И тъй като съвременните системи са склонни да създават голям брой c групи, използването на SLAB е по-малко ефективно.
Според него чрез споделяне на страниците на плочата между различни групи памет и чрез използване на преработена система, при която счетоводството се извършва по обект, а не по страница, човек би имал в ядрото на Linux оптимизиран контролер на паметта което предлага много по-ефективно ниво на използване.
Предложената корекция на Gushchin съдържа два полунезависими елемента: API за зареждане на подстраница, който може да се използва в бъдеще за счетоводни цели, и API mem_cgroup_ptr.
Тестове, извършени с новия контролер Паметта на Гущин са показали, че е възможно да получите между 35% и 42% повече памет в Linux във фронталната мрежа, кеш на база данни и DNS сървър и много други натоварвания.
Понастоящем предложението на Гущин е под знамето на „искане за коментар“. Ако бъде приет, той може да бъде интегриран във версията на ядрото на Linux за 2020 г.
Fuente: https://lkml.org/