Фрагментация оперативной памяти linux

концепция памяти в linux. дефрагментация памяти.

здравствуйте все! объясните чайнику как-нить попроще и по-русски об управлении памятью в linux. из англ. книг (при моем его знании) все видится оч.туманно. особенно оттого, что упор там делается на х86, а мне нужно по sparc. вижу, что есть разница. я не понимаю что означает «верхняя память», почему ядро не может замапить напрямую больше 800Мб нижней памяти, итд. есть ли толковые книги по-русски ?

и вот вопрос: у нас память в общем случае может быть физически оч.сильно дефрагментирована, причем достаточно маленькими блоками (по 1 Мб). может ли выдержать такое linux без страшных перемен в ядре? сможет ли он загрузится?

Re: концепция памяти в linux. дефрагментация памяти.

>я не понимаю что означает «верхняя память»

существует при области(на деле больше, но они есть далеко не на все архитектурах): dma (с нем может обшаться «кривое» оборудование), normal (ну тут все в общем понятно), и high (ее ядро не может размапить напрямую)

для x86 область high временно отображается на 1Gb-128Mb..1G и от туда с ней уже можно работать. этот костыль придуман из-за ограницения ахритектуры. на sparc’а ситуация обстоит подобным же образом.

>есть ли толковые книги по-русски ?

>и вот вопрос: у нас память в общем случае может быть физически оч.сильно дефрагментирована, причем достаточно маленькими блоками (по 1 Мб).

ну разве это маленькие блин? не смешите мои копыта. современные алгоритмы мэммори аллокатора в ядре очень хороши и добится большой фрагментации (>3-5%) практически не возможно (ну ладно, не возможно с нормальный аллокатором памяти)..

>может ли выдержать такое linux без страшных перемен в ядре?

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

>сможет ли он загрузится?

о, как все оказывается запущено. ну когда ядро запускается в памяти ничего нет => нет фрагментации

ps: может здесь есть неточности, давно дело было..

Re: концепция памяти в linux. дефрагментация памяти.

большое спасибо за ответ.

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

>этот костыль придуман из-за ограницения ахритектуры не разясните ли — каких именно ограничений ? может это всё мне прояснит 🙂

>>есть ли толковые книги по-русски ? >нет. а переводы? 🙂 нигде не найду ссылок. только на частичные переводы типа www.iakovlev.org причем без самого интересного

Re^2: концепция памяти в linux. дефрагментация памяти.

> я говорю о _физической_ (причем случайной) фрагментации. т.е. банки памяти могут отсутствовать кое-где (сгореть) .

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

Был какой-то патч для ядра(вроде badram называется), который позволяет указывать, какие части памяти трогать не надо. Наверно, оно должно помочь.

Re: концепция памяти в linux. дефрагментация памяти.

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

в linux «плоская» модель памяти, и такая ситуация не возможно (по крайней мере на x86’ой архитектуре). а если бы и была возможно то по логике вещей должна обрабатываться не ядром, а контролером памяти.

>не разясните ли — каких именно ограничений ? может это всё мне прояснит 🙂

гм.. ядро по дефолту линкуется на смешение в 1Gb. и все адресное пространство разбивается на две чати — 1Gb — ядро, 3Gb — пользовательские процессы. (опытным путем было установленно что это наилучшее разбиение). однако из-за этого как раз и возникает проблема: ядро не может на прямую адрисовать 3Gb.

переводы. из актуальных есть три книжки

1. «азбука ядра»(«A Top-Down Approach for x86 and Power PC Architectures») чтобы ее читать в переводе надо знать ангицкий (как это не парадоксально), т.к приходится догадываться о чем же говорилось в первоисточнике (перевод крайне корявый)

2. ядро linux (Understanding the Linux Kernel, 3rd Edition, OReilly) с нормальным переводом (хотя в оригинале опять же лучше, и при том в открытом доступе) стоит кучу денег.

3. разработка ядра linux роберта лава, второе издание. тоже достойная книжка в которой очень кратно рассматриваются основные подсистемы, структуры и алгоритмы ядра. перевод хороший (и даже есть отсканенная нелицензионная pdf’ка этого перевода)

вроде больше переводов небыло.

Re: концепция памяти в linux. дефрагментация памяти.

1) в принципе необязательно, ядро можно грузить по любому физическому адресу (если там конечно RAM/flash 🙂 ) если pre-MMU код это позволяет.

2) Ядро занимает один гигабайт в виртуальном адресном пространстве на IA32 (0xc0000000 — 0xffffffff), так что напрямую (1:1) можно отмапить только 1 гигабайт памяти. Окно виртуальных адресов оставлено для того чтобы туда можно было мапить железяки, etc)

3) нет, не видел таковых

Re: концепция памяти в linux. дефрагментация памяти.

> я не понимаю что означает «верхняя память»,

Источник

Устранение фрагментации памяти на linux как в .net

В .net gc переодически перераспределяет память, выделенную под конкретную программу, тем самым уменьшая фрагментрованность памяти. Как можно сделать такую же операцию на С в linux?

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

Тормоза на выделение/удаление памяти больше времени займет

Масдайный gc работает довольно таки шустро.

Да и для чего это нужно, если не секрет?

Прикладной цели нет, чисто интерес.

и еще

Тормоза на выделение/удаление памяти больше времени займет

Я полагаю, здесь просто нужна бистрая реализация memcpy.

Масдайный gc работает довольно таки шустро.

На фоне тормозящих прог, ну да (:

Логика вроде не сложная копирование памяти в новую непрерывную область, не?

g_slice_alloc частично решит проблему фрагментации. И как дефрагментировать? Придется ведь тогда менять значения указателей.

Логика вроде не сложная копирование памяти

Афаик, memcpy реализован как побайтное копирование.

Интересно, не знал. Но после прочтения возник вопрос: g_slice_alloc — это же только для выделения памяти, не для перераспределения?

Например, после выполнения

Это первая реализация, что пришла в голову.

На сях такое не сделать. Для сей не удастся реализовать копирующий сборщик мусора.

>> Масдайный gc работает довольно таки шустро.

О да, я около года поработал над сервером fragoria.ru. GC работает шустро только когда проц мощный, делать ему нечего и структура данных очень простая.

И да, возьми моно. Или ты думаешь в линуксе Си круче чем в винде и там есть GC? 🙂

> возвратится таблица соответствий: старый адрес — новый адрес.

такая таблица не поможет «исправить» указатели, которые указывают не на начало выделенной области

Java же!

Кто-то должен был это сказать

>g_slice_alloc — это же только для выделения памяти, не для перераспределения?

Его использование уменьшит фрагментацию, но он не годится для строк и массивов, только для структур.

и че с этой таблицой делать?

А чем результаты поиска в гугле не устроили?

Для C компактифицирующий GC нереально сделать.

А это ничего, что в одном языке есть указатели, а в другом их в принципе нет? 🙂

В .net gc переодически перераспределяет память, выделенную под конкретную программу, тем самым уменьшая фрагментрованность памяти. Как можно сделать такую же операцию на С в linux?

Предлагаю сначала хоть немного разобраться в основах .NET, C и управления памятью.

> И да, возьми моно.

В моно gc память не дефрагментирует, ЕМНИП.

Пока только экспериментальная поддержка есть http://www.mono-project.com/Compacting_GC в ветке 2.7

> И как дефрагментировать? Придется ведь тогда менять значения указателей.

Придется юзать не указатели, а более хитрую сущность, которая будет сама по себе жрать больше места и работать медленнее, зато позволит GC перекладывать объекты. Но это уже будет не C.

Для си ты не сделаешь дефрагментацию. Чтобы сделать надо превратить си в другой язык с кучей инфы о типах и переменных в рантайме.

Для си++ можно сделать defragmentable_ptr но проще пулы использовать.

И да, переменные на стеке рулят.

«дифрагментацией» памяти в С занимается ядро.

>Чё? Гм. ну поищи в гугле slab allocator. или хотя бы buddy allocator чтоли.

>Придется ведь тогда менять значения указателей.
если дефрагментацией будет заниматься ядро — не придется.

если дефрагментацией будет заниматься ядро — не придется.

Зачем это нужно? Очередная ловля блох?

Он же внутриядерный. Как он будет дефрагментировать то что выделено malloc’ом в юзерспейсе.

>Он же внутриядерный. Как он будет дефрагментировать то что выделено malloc’ом в юзерспейсе.

Продефрагментируй лучше мозги. без обид.

>> Продефрагментируй лучше мозги. без обид.

Какие умные анонимусы появились на лоре.

Я сделал млн malloc-ов по 1024 байта (1Г). Потом из каждых 4х блоков 1й оставил, а 2й,3й,4й — освободил. Итого: я использую 256М, а занят 1Г.

Как мне может помочь slab allocator?

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

менеджер память нужно свой писать

ляпнул чето. ваще то этим поставленную задачу не решить.

А это ничего, что в .NET указатели в принципе очень даже есть? И Си можно полноценно компилировать в .NET, между прочим.

>И да, переменные на стеке рулят.

Реквестирую std::string полностью на стеке!

И Си можно полноценно компилировать в .NET, между прочим.

Да, но GC в таком случае просто не будет работать.

Я сделал млн malloc-ов по 1024 байта (1Г).
Потом из каждых 4х блоков 1й оставил, а 2й,3й,4й — освободил.
Итого: я использую 256М, а занят 1Г.

Скорее всего, в случае современного х86 , 1Г занят не будет. Надо читать про аритектуру проца/OS на пердмет protected mode. Например начать отсюда http://en.wikipedia.org/wiki/Protected_mode. Краткая мораль: цифра которую вы видите по printf(«%X»,pointer); не имеет прямого отношения к физическому положению в памяти.

Прочь руки испачканные GC от системного программирования :).

>> Скорее всего, в случае современного х86 , 1Г занят не будет.

Будет. я даже проверил.

sbrk при малоках отодвигает границу, а т.к. страница = 4к, то ни одна из страниц не освобождается.

> Да, но GC в таком случае просто не будет работать.

Будет. Не говорите глупостями.

Да, но GC в таком случае просто не будет работать.

Будет. Не говорите глупостями.

Не будет. Как ты вообще себе представляешь автоматическое управление памятью, выделенной в С?

Источник