Низкая пропускная способность памяти в Linux-Embedded (ARM) - PullRequest
Новая
       10

Низкая пропускная способность памяти в Linux-Embedded (ARM)

3 голосов
/ 09 сентября 2009

Я использую ARM926EJS. Я получаю на 20% больше скорости памяти в тесте копирования памяти без Linux (как исполняемый файл Getting Started). Но в Linux тот же код работает на 20% медленнее.

Код 

 
/// Below code just performs burst mode memcopy test.        
void asmcpy(void *a, void *b, int iSize)
{
   do
  {
    asm volatile (
             "ldmia %0!, {r3-r10} \n\t"
             "stmia %0!, {r3-r10} \n\t"
             :"+r"(a), "+r"(b)
             :
             :"r"(r3),"r"(r4),"r"(r5),"r"(r6),"r"(r7),"r"(r8),"r"(r9),"r"(r10)
             );
  }while(size--)
}

Я проверил, что никакой другой процесс не потребляет процессорное время в Linux. (Я проверил это с помощью команды time, она показывает реальное время такое же, как время usr )

Скажите, пожалуйста, в чем может быть проблема с Linux?

Спасибо и всего наилучшего.

ДОБАВЛЕНО:

мой тестовый код 

int main()
{
  int a[320 * 120], b[320 * 120];

 for(int i=0; i != 10000; i++)
 {
   /// Size is divided by 8 because our memcpy function performs 8 integer load stores in the iteration
   asmcpy(a, b, (320 * 120) / 8);
 }
}

Исполняемый файл Getting Started - это файл bin, который отправляется в ОЗУ через последовательный порт и выполняется напрямую, переходя по этому адресу в ОЗУ. (без необходимости использования ОС)

ДОБАВЛЕНО.

Я не видел такой разницы в производительности на других процессорах. Они использовали SD RAM, Этот процессор использует DDR Ram. Может ли это быть причиной?

ДОБАВЛЕНО. Data Cache не включается при запуске кода, а Data Cache работает в режиме Linux, поэтому в идеале все данные должны кэшироваться и получать к ним доступ без какой-либо задержки ОЗУ, но, тем не менее, Linux работает на 20% медленнее.

ДОБАВЛЕНО: Мой микроконтроллер - LPC3250. Оба теста были протестированы на одной и той же внешней памяти DDR.

Ответы [ 4 ]

10 голосов
/ 09 сентября 2009

Этот чип имеет MMU, поэтому Linux, вероятно, использует его для управления памятью. Может быть, просто его включение приводит к некоторому снижению производительности. Кроме того, Linux использует ленивую стратегию выделения памяти, назначая страницы памяти процессу только при первом обращении к нему. Если вы копируете большой кусок памяти, MMU будет генерировать сбои страниц, чтобы попросить ядро ​​выделить страницу, находясь в цикле. На младшем процессоре все эти переключатели контекста вызывают сброс кеша и вносят заметное замедление.

Если ваша система достаточно мала, попробуйте версию Linux без MMU (например, uClinux ). Возможно, это позволит вам использовать более дешевый чип с аналогичной производительностью. Во встроенных системах каждая копейка считается.

обновление: Некоторые дополнительные сведения:

Каждый процесс Linux получает свои собственные отображения памяти. Сначала это включает только ядро ​​и (возможно) исполняемый код. Все остальные линейные 4 ГБ (на 32-битной) кажутся доступными, но им не назначены страницы ОЗУ. Как только вы читаете или записываете нераспределенный адрес памяти, MMU сигнализирует об ошибке страницы и переключается на ядро. Ядро видит, что у него все еще есть много свободных страниц ОЗУ, поэтому выбирает одну, назначает ее точке отказа и возвращает ваш код, который завершает прерванную инструкцию. Следующий не провалится, потому что вся страница (обычно 4 КБ) уже назначена; но через несколько итераций он попадет в другое не назначенное место, и MMU снова вызовет ядро.

3 голосов
/ 09 сентября 2009

Как вы проводите время? В вашем примере нет временного кода.

Вы уверены, что не измеряете время загрузки / выгрузки процесса?

Является ли тактовая частота процессора одинаковой в обоих случаях?

При использовании внешней SDRAM синхронизация ОЗУ одинакова в обоих случаях?

Включен ли кеш данных в обоих случаях?

Clifford

2 голосов
/ 10 сентября 2009

Начало работы - это не просто исполняемый файл. Должен быть какой-то код для установки регистра контроллера DDR.

Если кеш также включен, то должен быть и MMU. Я думаю, что на ARM926EJS вы не можете иметь кеш данных без MMU.

Я полагаю, что каждое переключение контекста приводит к очистке кеша, потому что кеш практически проиндексирован, практически помечен, а ядро ​​и пользовательское пространство не используют одно и то же адресное пространство, поэтому у вас, вероятно, больше нежелательной очистки кеша, чем без OS.

Вот бумага с некоторыми аспектами стоимости очистки кэша VIVT при работе с Linux

1 голос
/ 10 сентября 2009

Какой микроконтроллер (а не только процессор ARM) вы используете?

Возможно ли, что при запуске не-Linux тестируемый массив является ОЗУ на самом устройстве микроконтроллера, тогда как в тесте Linux тестируемый массив находится во внешней ОЗУ? Внутренний ОЗУ обычно доступен намного быстрее, чем внешний ОЗУ - это может быть причиной замедления теста Linux, даже если кэширование данных включено только для запуска Linux.

...