☰

Разделение на 32-битные архитектуры

tag-icon • tag-icon linux linux-kernel
Разделение на 32-битные архитектуры

Я нахожусь в процессе интеграции прикладного программного обеспечения в пользовательский дистрибутив Embedded Linux от поставщика чипсета. Это продукт на базе ARM, над которым я работаю. Я заметил, что ядро ​​собирается в 64-битной версии, но остальная часть пользовательского пространства — 32-битная.

Есть ли какие-либо преимущества в производительности при построении ядра как 64-битного, даже если пользовательское пространство находится в 32-битном состоянии? SOC основан на ARM cortex-a53.

Кто-то предположил, что пользовательское пространство в 32 бита приведет к уменьшению объема оперативной памяти для пользовательского пространства. То же самое должно относиться к ядру, но ядро ​​64 бит. Я предполагаю, что есть прирост производительности?

некоторые подробности об оборудовании:

  • ARM кора a53
  • 1 ГБ ОЗУ

PS: Я не могу раскрыть имя поставщика из-за ограничений по конфиденциальности.

решение1

Виртуальное адресное пространство процесса Linux разделено на две области:

  • пространство ядра
  • пространство пользователя.

Разделение на 32-битные архитектуры

На 32-битной архитектуре, например, arm или i386, традиционное разделение составляет 3:1, как показано ниже:

    +--------+ 0xffffffff
    | Kernel |
    +--------+ 0xc0000000
    |        |
    | User   |
    |        |
    +--------+ 0x00000000
  • Пространство ядра - 1 ГиБ
  • Пользовательское пространство - 3 ГиБ

Таким образом, ядро ​​может отобразить максимум 1 GiB физической памяти в любой момент времени, но есть и дальнейшее разделение, поскольку нам нужно виртуальное адресное пространство для временных карт, чтобы получить доступ к остальной части физической памяти. Разделение выглядит следующим образом:

  • нижние 896 МБ (от 0xc0000000 до 0xf7ffffff) напрямую сопоставлены с физическим адресным пространством ядра
  • оставшиеся 128 МБ (от 0xf8000000 до 0xffffffff) используются ядром по требованию для отображения в верхнюю память.

Распорядок следующий:

                                                 physical memory 2 GiB 
                                          +------> +------------+
                                          |        |  1152 MiB  |  
                                          |        |            |  
    +------------------+ 0xffffffff  -----+        |  HIGH MEM  |  
    | On Demand 128MiB |                           |            |  
    +------------------+ 0xf8000000  ------------> +------------+  
    |                  |             ------+  
    |  Direct mapped   |                   +-----> +------------+   
    |    896 MiB       |             --+           |   896 MiB  |        
    +------------------+ 0xc0000000    +---------> +------------+

Таким образом, ядро ​​Linux через интерфейс highmem обеспечивает косвенный доступ к этой физической памяти в диапазоне 2/4/6/8 GiB. Но, есть сопутствующие затраты на создание временных отображений, которые могут быть довольно высокими. Архитектура должна манипулировать таблицами страниц ядра, TLB данных и/или регистрами MMU.

О 64-битных архитектурах

Разделение 3G/1G не применяется. Из-за огромного адресного пространства можно выбрать схему разделения между пользовательским пространством и пространством ядра, которая позволяет отображать всю физическую память в адресное пространство ядра. Таким образом, экономя все накладные расходы на временные отображения, которые несет 32-битная архитектура.

Поддержка высокой памяти является необязательной в случае ядра Linux на 64-разрядной архитектуре и даже отключена в случаях Linux на 64-разрядной архитектуре.

Ссылка:Обработка большого объема памяти в Linux.

Связанный контент