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

Question

Я использую 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. (Я проверил это с помощью команды времени, он показывает в реальном масштабе времени такое же, как USR время)

Пожалуйста, сообщите мне, что может быть проблемой с Linux?

Thanks & С уважением.

ДОБАВЛЕНО:

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

 
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); 
} 
} 

Начало работы исполняемый бин файл, который отправляется в ОЗУ, используя последовательный порт и выполняет непосредственно, прыгая по этому адресу в памяти. (без ОС)

ADDED.

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

ADDED. Кэш данных не активирован при запуске кода и кэширование данных в режиме Linux, поэтому в идеале все данные должны кэшироваться и получать доступ без какой-либо задержки в оперативной памяти, но все же Linux на 20% медленнее.

ADDED: Мой микроконтроллер LPC3250. Оба теста были протестированы на одной внешней ОЗУ DDR.

Answer 1

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

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

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

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

Answer 2

Как вы выполняете синхронизацию? В вашем примере нет кода синхронизации.

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

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

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

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

Clifford

Answer 3

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

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

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

Вот в paper с каким-либо аспектом на стоимость VIVT кэш флеш при запуске Linux

Answer 4

Что микроконтроллер (а не только то, что ARM CPU) вы используете?

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