Перемещаемые секции в ELF32, доработка ядра для использования внутреннего ОЗУ процессора Опции

[Hoodwin]

В некоторых процессорах, с которыми приходится иметь дело, память уровня L1 может не полностью превращаться в кэш первого уровня. Память L1 намного быстрее обычной пользовательской памяти Linux. в моем случае memcpy, выполненный в обычной памяти (DDR2 SDRAM через кэши L2 и L1) дает скорость около 100 МБ/с. Тот же вызов с указателями в памяти L1 дает скорость более 6 ГБ/c, то есть в 60 раз быстрее. Многие счетные приложения могли бы существенно выиграть, если бы использовали эту память напрямую, а не через кэш. Тем более, что в нашем случае более половины этой памяти (48К из 80К) именно только памятью и являются.

Возникла следующая идея - доработать ядро линукс так, чтобы при загрузке процесса в память, оно все секции, начинающиеся с префикса, скажем, ".l1_" (например, ".l1_text"), при возможности (наличии места) переносило само в память L1, и динамически перелинковывало все указатели на новое место. В этом случае программист получает возможность писать приложение как обычно, и только отдельным данным и коду назначать атрибут размещения в секции с другим именем. Собственно, именно так и делается при обычном программировании без Linux. Но загрузчик ELF мог бы сам выделять место в L1, чем гарантировать совместное использование общей памяти разными процессами. Причем, если память L1 в достаточном объеме отсутствует, то ничего страшного не происходило бы, просто в журнал ядро записывало бы предупреждение о невозможности загрузить процесс оптимально.

Однако пока я копался в деталях загрузки ELF, уперся в простую проблему. При сборке линкер обычно не делает никаких relocation таблиц, а кладет секции друг за другом в виртуальном адресном пространстве процесса по мере того, как у него проясняется расклад по всем объектным модулям. То есть, перенести отдельную секцию неявно не очень то и получается, надо как-то линкер предупредить, что секция будет динамически линковаться потом, и что нужно составить для нее таблицу символов и поместить в объектный модуль. Так вот, вопрос уперся в то, можно ли такое сделать, и если можно, то как?

Еще раз повторю свое видение процесса загрузки такого процесса.
1) Загрузить процесс стандартным образом.
2) Для каждой секции с именем, начинающимся на заданный префикс, выполнить попытку переноса в L1.
3) ... для этого попытаться выделить место в L1, проверить наличие таблицы и при успехе скопировать секцию в L1, перенести все ссылки процесса в новое место.
4) если попытка переноса не удастся, то написать сообщение в журнал ядра.

[Hoodwin]

И все же я пока не получил ответа на вопрос, можно ли слинковать ELF с помощью обычного так, чтобы одна секция была перемещаемой? То есть для всех символов из этой секции имелась бы таблица символов, а для всех ссылок на эти символы имелась таблица relocation-ов.

[Harbour]

И все же я пока не получил ответа на вопрос, можно ли слинковать ELF с помощью обычного так, чтобы одна секция была перемещаемой? То есть для всех символов из этой секции имелась бы таблица символов, а для всех ссылок на эти символы имелась таблица relocation-ов.

-fPIC делает это для всех .text* секций

[sasamy]

-fPIC делает это для всех .text* секций

PIC - это прямой и рекомендуемый метод, но существует еще динамическая релокация.

То есть, нужно будет не только секцию .l1_data передвинуть, но и в секции .text подправить непосредственные операнды в командах загрузки адреса строки.

Не совсем так по крайней мере на архитектурах которые поддерживают динамическую релокацию. Вот наглядная статья, правда на примере x86 и динамических библиотек
http://eli.thegreenplace.net/2011/08/25/lo...ared-libraries/

У блэкфинов в ядре есть (или был ?) свой специальный парсер elf который определял что секцию надо помещать в sram, в ванильном ядре этого нет - sram используется для буферов в драйверах.
http://lkml.indiana.edu/hypermail/linux/ke...06.2/00159.html
правда я не понял - почему они genalloc не используют в качестве аллокатора
http://lxr.free-electrons.com/source/lib/genalloc.c

Сообщение отредактировал sasamy - Dec 26 2013, 00:44