четверг, 11 марта 2010 г.

SBCL и громадные страницы

Есть у SBCL одна неприятная черта: он манипулирует памятью постранично, страница практически везде 4кб. То есть просит память у ядра по 4кб, меняет атрибуты доступа постранично и так далее. А так как память он зело любит, то ворох мелких страниц загромождает vma в ядре, а постраничный mprotect в начале каждого цикла сборки мусора - это ахтунг (каждый сисколл "весит" около 1000 тактов плюс потери от сброса кэша L1).

Проблема с mremap'ом решается довольно простой доработкой сборщика мусора, там можно выделять непрерывные регионы страниц и менять атрибуты всем сразу. Вообще, как-то этот момент в SBCL подзапущен... Но ничего, поправим, улучшим, допилим.

Ещё давно хочется научить SBCL работать со страницами другой гранулярности. Современные x86-64 поддерживают т.н. huge pages размером ажно 2 мегабайта. Профита от таких страниц очень много, недаром тот же Оракел очень сильно рекомендует настраивать систему на их использование. Размер страницы в исходниках SBCL указывается всего в одном месте, в параметрах бэкенда, но, как обычно бывает, при слишком диком изменении параметра всплывает куча нехоженных косяков. Где-то полгода назад у меня ничего не получилось с доработкой, но сегодня какое-то мегахакерское настроение было, все всплывшие проблемы порешал одну за другой. Даже осуществил давнюю мечту: нашёл elf'овый бутстрап, который грузит образ, и потыкался в gdb :) Во всём оказались виноваты автоматически ненастраиваемые неведомые константы, которые пришлось выискивать в коде.

В общем, сейчас можно выделять память любой гранулярности, в том числе и требуемые 2мб, но перевод аллокатора на huge pages требует некоторого допила. Дело в том, что используемый анонимный mmap, не привязанный к дескриптору, не требует указания смещения, поэтому совершенно не годится для hugepages, которые доступны только ммапом на спец. файл. Соответственно, придётся аллокатору немножко интеллекта добавить, дабы он знал, какие части hugepages-файла заняты.

Буду надеяться, что работу завершу, и в скором времени SBCL просто немерянно разгонится по части работы с памятью. Особенно эффект будет заметен на жирном софте, который разворачивается на гигабайты памяти. Система тоже не будет надрываться при переключении контекста с/на SBCL, т.к. vma-цепочки сократятся ажно в полтыщи раз.

6 комментариев:

  1. Вау, пусть "мегахакерское настроение" тебя не покидает в течении долгих лет ! ;)

    ОтветитьУдалить
  2. Ага, в рассылках этот вопрос помоему уже поднимался, можно поискать к чему обсуждаторы пришли.

    ОтветитьУдалить
  3. Ура, так с утра меня еще никто не радовал! Спасибо огромное!

    ОтветитьУдалить
  4. Кстати как человек копавшийся внутри sbcl скажите что он так память жрет? А то потребление больше в разы чем на других реализациях. Интересно с этим можно что нибудь сделать?

    ОтветитьУдалить
  5. to ln_123: Выравниваний много, как в коде, так и в данных. Но это же скорости ради! Пусть лучше память жрёт, зато в сотни раз быстрее работает, чем другие, более скромные реализации.

    ОтветитьУдалить
  6. Ухты, теперь к этому кучерявому монстру ещё один недоделанный добавился...

    ОтветитьУдалить

Архив блога