Сколько страничек в вашей памяти?

08.02.2006 03:47:28

Сижу, значит, погружаюсь в архитектуру PowerPC. Не так давно погрузился до того, что узнал интереснейшую штуку — в PowerPC стандарта Book-E поддерживается 16 размеров страниц, причем, поддерживается одновременно. То есть, вот страничка на 1КБ, а следом на 256МБ — и это нормально. Правда, в подопытном для меня экземпляре PowerPC 440 поддерживается только 8 размеров, но это не так важно.

Интересно другое. Подготовленный читатель, небось, уже представил себе как старый добрый malloc() берет да выделяет пользователю страницу размером близкую с необходимому куску памяти (в случае отсутствия куска нужного размера в уже забитых страницах процесса… в общем, понятно). Если подумать больше, то можно прийти к выводу, что это должно быть очень даже полезно и приятно для современных применений, поскольку сегодня память обычно требуется выделять ведрами.

А хорошо подобранные под каждый случай выделения памяти странички дают нам менее забитый TLB, что есть чудовищно круто, поскольку промахи TLB — не самая приятная штука. И, потом, есть еще своппинг. Понятно, с этой точки зрения страницы размером где-то более 2-4 МБ уже становятся накладным мероприятием, но! разницу между чтением/записью на диск, например, 4КБ и 256КБ вы никогда не заметите. В то же время, это либо перемещение 64 страниц, либо одной — почувствуйте разницу.

Сравниваем это с x86, где у нас варианта всего два, при том никак не одновременных — либо 4КБ, либо 4МБ (справедливости ради — в PowerPC 7xx и 9xx рулят страницы по 4КБ и, иногда, по 16 МБ, правда, их можно использовать одновременно). Первое суть есть онанизм, мелковато, когда память меряется сотнями мегабайт. Второе суть есть дурдом, поскольку своппинг достаточно неплохо убивает, хотя, если работать только с реальной физической памятью, то имеет свой интерес, были даже такие патчи к ядру Linux.

В результате можно прийти к выводу, что умело варьировать размеры страниц в районе 4 — 512КБ должно быть довольно полезно.

Спускаемся в дерево исходников Linux, внимательно заглядываем в каталог ‘include/asm-ppc’. Видим файл ‘page.h’. А в нем:

/* PAGE_SHIFT determines the page size */
#define PAGE_SHIFT      12
#define PAGE_SIZE       (1UL << PAGE_SHIFT)

То есть, на довольно интересной платформе, позволяющей делать всякое, мы по прежнему онанируем со страничками в 4КБ. При этом, есть еще один неприятный эффект — фрагментация виртуальной памяти при том, что иногда требуется выделять цельные куски памяти больших размеров.

О последнем, кстати, хорошо показано в этих слайдах. Правда, там использовался изврат с надстройкой выделения больших кусков над страничками по 4 КБ. При этом потеряли 0,5% производительности, но значительно выиграли во внешней фрагментации (при этом, надо заметить, использовались статичные куски по 256 КБ, не варьируемые).

Безусловно, есть технические трудности организации выделения памяти варьируемыми кусками (даже в тесте выше использовалась статика, хоть и большая), однако, так ли они велики, и что здесь сложнее — придумать эффективные структуры данных и алгоритм, нежели потом описать все это на C? Вопрос остается открытым.

Впрочем, на пути к варьируемым страницам есть и другие препятствия, например, системный вызов getpagesize(), который должен возвращать размер страницы. Стоит ли говорить, что это значит? Правда, справедливости ради, надо отметить, что его работоспособность не гарантируется для всех архитектур, а из POSIX 1003.1-2001 этот вызов вообще исключили…

Еще один убитый Reiser4

25.01.2006 00:12:38

Срочно звездочку на погон! Кажется, я умудрился совершить еще одну большую ошибку в общении с Reiser4 и бОльшая часть моей музыки да разного видео ушла погулять в /dev/null. Первая ошибка была очевидна и просто глупа с моей стороны — случайно загрузился с неправильным ядром (хотя было правильное и оно у меня нормально работало) в страшные времена тотальной дестабилизации Reiser4 на пути к официальному ядру.

Теперь вот предстоит выяснить, все-таки я два раза дурак или в fsck.reiser4 есть ошибка. Мой новенький блестящий винчестер на 250 ГБ пал жертвой fsck.reiser4 после того, как мне подумалось, что неплохо бы проверить, все ли в порядке после нескольких «Badness» от ядра 2.6.15-rc5-mm3 в его сторону. Узнал, что не все в порядке, есть одна маленькая inconsistency. Ну и сделал «fsck.reiser4 —build-fs», как сам fsck посоветовал. Теперь разглядываю каталог «lost+found», размышляю о всяком.

Что интересно, Reiser4progs уже есть версии 1.0.5, а у меня почему-то до сих пор 1.0.4 стоят. Если это из-за этого, значит я действительно совсем дурак и пора прекратить жесткие эксперименты — выходит себе дороже. Однако, весело. Написал в reiserfs-list, Ганс Райзер поведал, что Виталий (который занимается fsck.reiser4) сейчас в отпуске. Ладно, подожду диагноза, что уж делать. Скорее всего диагноз поставят мне. 🙁

Как-то нехорошо у меня все складывается с R4. 🙁

Обновление:
Урра!!! Кажется, диагноз поставили. Как и думалось, я дурак дважды. ;-)))
Обновление:
Вай, я еще и тут ошибку допустил — Badness исходил от 2.6.15-mm4…

Удаленные приложения или X еще жив

09.01.2006 01:31:10

Определенно, в X все-таки что-то есть. Вот, например, стоит мой ноутбук с Athlon 1700+ и 768 МБ памяти, мается от безделья. А рядышком замученный жизнью Celeron 480 со 128 МБ мозгов. И второму очень не нравится одновременная работа OpenOffice 2.0 и Konqueror, особенно когда тот мучается, загружая HTML на 200 КБ с тремя сотнями картинок. Однако, вовремя вспомнив про то, что X умеет работать по сети можно взять первое попавшееся руководство и запустить требовательные приложения на быстрой машинке.

Единственная возникшая загвоздка заключалась в том, что нынче модно запускать X с параметром «-nolisten tcp» (так делает kdm по умолчанию), что хорошо для безопасности при исключительно локальной работе, но впрямую противоречит нашим целям. Убираем, перезапускаем X и вуаля! Все прекрасно работает.

Все-таки что-то есть в X. 🙂