|
Перемещаемые секции в ELF32, доработка ядра для использования внутреннего ОЗУ процессора |
|
|
|
Dec 24 2013, 07:24
|
Знающий
   
Группа: Участник
Сообщений: 881
Регистрация: 21-03-10
Из: _// \\_
Пользователь №: 56 107

|
В некоторых процессорах, с которыми приходится иметь дело, память уровня 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) если попытка переноса не удастся, то написать сообщение в журнал ядра.
|
|
|
|
|
 |
Ответов
|
Dec 25 2013, 21:57
|
Знающий
   
Группа: Участник
Сообщений: 881
Регистрация: 21-03-10
Из: _// \\_
Пользователь №: 56 107

|
К сожалению, в этих материалах тоже нет ответа на вопрос о перемещении секций и их сочетании с секциями в обычных данных. никаких совпадений на 'reloc' я там не нашел. Ну вот допустим пример такой: Код char __L1_data some_string[] = "Example string";
int main() { printf("%s\n", some_string);
return 0; } Очевидно, перед вызовом printf компилятор захочет загрузить в регистр адрес строки. Если секция в процессе загрузки процесса переедет, то и адрес строки изменится. То есть, нужно будет не только секцию .l1_data передвинуть, но и в секции .text подправить непосредственные операнды в командах загрузки адреса строки. В архитектуре c6x еще 32-битные данные нельзя загрузить в регистр одной командой, они грузятся двумя половинками по 16 бит. Поэтому и фиксапы будут весьма специфические. Насколько я представляю, они где-то в .rel.dyn должны попасть. Но вот при обычном связывании секция .l1_data будет размещена где-нибудь рядом с .data, вычислены реальные смещения относительно начала процесса, половинки которого будут подправлены при передаче аргументов в printf и в таблицы динамического связывание ничего не попадет. Поэтому секцию то я перенести могу, но работать оно будет по старым адресам. Ни в одном из найденных Вами документов вообще ничего про это не написано.
|
|
|
|
Сообщений в этой теме
Hoodwin Перемещаемые секции в ELF32 Dec 24 2013, 07:24 Harbour Всего-то придется переписать Linux memory manager,... Dec 24 2013, 08:21 Hoodwin Не понял про ld, зачем его патчить? Смысл как раз ... Dec 24 2013, 16:13 Harbour Ну и как тогда предполагается стандартному загрузч... Dec 25 2013, 06:22 Hoodwin ну, а что, просто секцию сделать relocatable нельз... Dec 25 2013, 06:37 sasamy Цитата(Hoodwin @ Dec 25 2013, 10:37) В мо... Dec 25 2013, 09:44 Hoodwin За ссылку спасибо! Но это все же вариант не са... Dec 25 2013, 09:52 sasamy Цитата(Hoodwin @ Dec 25 2013, 13:52) хоте... Dec 25 2013, 10:43 Hoodwin Ну вот идея как раз в том и состояла, чтобы не гор... Dec 25 2013, 11:38 sasamy Цитата(Hoodwin @ Dec 25 2013, 15:38) Ну в... Dec 25 2013, 12:20 Hoodwin И все же я пока не получил ответа на вопрос, можно... Dec 25 2013, 15:48 sasamy Цитата(Hoodwin @ Dec 25 2013, 19:48) И вс... Dec 25 2013, 20:13 Harbour Цитата(Hoodwin @ Dec 25 2013, 17:48) И вс... Dec 25 2013, 21:45  sasamy Цитата(Harbour @ Dec 26 2013, 01:45) -fPI... Dec 26 2013, 00:03 Hoodwin А правильно ли я понимаю, что в архитектурах без M... Dec 26 2013, 06:49
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|