Можем ли мы запустить Linux в чем-то быстрее, чем ОЗУ?

21

Это, возможно, глупый вопрос, и может быть результатом недоразумения. Я сейчас изучаю процессоры и память в частности. Я просто читал о том, насколько быстрее SRAM, чем DRAM, но дороже. SRAM очень дорогой: я немного покупал и нашел SRAM-карту с батарейным питанием на 16 МБ примерно за 400 долларов.

Недавно мой друг упомянул, что он запускает Puppy Linux в оперативной памяти, и что это быстро. Я заметил, однако, что крошечное ядро ​​Linux может быть даже меньше ... до 8 МБ! Это заставило меня задуматься: можем ли мы запустить Linux в SRAM? Этот вопрос даже правильно сформулирован?

Поиск в Google этого вопроса оказался неэффективным, но он поднял еще больше вопросов. Можно ли запустить Linux в L3 Cache? Intel Core i7 может иметь кэш L3, достаточно большой, чтобы вместить 8 МБ ... но я делаю категорическую ошибку? В чем разница между этим и встроенным Linux?

Вот в чем вопрос: можем ли мы запустить Linux в SRAM или L3 Cache? Есть ли что-нибудь быстрее? Как быстро мы можем linux !?

г.

Ziggy
источник
3
Встроенные Linux часто запускаются на оперативной памяти или энергонезависимой памяти. Встраиваемые Linux часто просто урезаны, чтобы работать только на определенном оборудовании, или использовать некоторые менее распространенные параметры ядра, такие как низкая задержка
Journeyman Geek
2
Интересно, есть ли практическое применение для этого вопроса?
Роберт Нистрой
4
+1 за использование «linux» в качестве глагола (в последнем предложении)!
Vorac

Ответы:

20

Linux или любая другая ОС не знает, как работает RAM. До тех пор, пока контроллер памяти настроен правильно (например, частота обновления установлена ​​для не-SRAM), ОС не заботится о том, работает ли она на простой динамической памяти (обычное ОЗУ), оперативном ОЗУ в режиме быстрой страницы (FP RAM, из C64-ish). раз), расширенный ОЗУ в режиме вывода данных (EDO), синхронное ОЗУ (SDRAM), любой из SDRAMS с двойной скоростью передачи данных (DDR 1/2/3) и т. д.

Все они поддерживают чтение и запись из разных мест. Все будет работать.

Теперь кеш немного другой. Вам не нужно писать в него, чтобы содержимое изменилось. Это будет мешать. Тем не менее, это несколько полезно. Я знаю, что coreboot использует кеш как своего рода память во время загрузки, прежде чем контроллер памяти будет правильно настроен. (Для получения подробной информации, посмотрите видео с выступлений coreboot во время FOSDEM 2011).

Так что в теории да, вы можете использовать это.

НО : для практических задач система с «обычной» «средней» памятью объемом 1 ГБ будет работать намного лучше, чем с очень быстрой памятью всего в несколько МБ. Это означает, что у вас есть три варианта:

  1. Стройте вещи обычным «дешевым» способом. Если вам нужна большая скорость, добавьте несколько десятков дополнительных компьютеров (все с «медленной» памятью)
  2. Или собрать один компьютер, цена которого будет в десятки раз выше, а производительность будет в десятки раз меньше.

За исключением очень редких случаев, последнее не имеет смысла.

Hennes
источник
6
Многие ЦП поддерживают режим «кэш-как-ОЗУ» через регистры, специфичные для модели ЦП (MSR). Также обратите внимание, что SRAM потребляет больше энергии, чем DRAM, и это также является конструктивным фактором. Если кэш процессора был достаточно большим или ядро ​​достаточно маленьким, вы можете включить этот режим кэширования как оперативной памяти и сохранить его выполнение полностью в SRAM на процессоре. У вас будет ограниченный объем оперативной памяти для запуска программ и т. Д. потому что AFAIK cache-as-RAM и обычный режим не будут работать одновременно. Хотя я могу ошибаться по этому поводу. Даже если бы это было так, большая часть скорости процессора в наши дни обусловлена ​​использованием кеша L2, L3.
LawrenceC
@Hennes, разве Linux заботится только об (отображенных) адресах памяти?
Элвин Вонг
SDRAM - это синхронная D (динамическая) RAM, а SRAM - статическая RAM. Я не знаю, на кого вы хотели сослаться в первом абзаце, и у меня нет представителя, чтобы делать «тривиальные» правки, но, возможно, вы могли бы это исправить? Кроме этого, хороший ответ.
CVn
Я не против уточнить, но я не уверен, что вы хотите уточнить. Можете ли вы добавить это в комментарии, и я отредактирую это.
Hennes
Когда я впервые прочитал этот комментарий, я увидел: «Linux или любая другая ОС умирает, не зная, как работает ОЗУ». Ваш срыв хорош: я думаю, у меня не было иллюзий, что это будет «лучше». Мне просто интересно, можно ли это сделать.
Зигги
8

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

Единственный момент, когда кэш-память затем копируется обратно в обычную оперативную память, - это когда ПК переходит в режим ожидания S3. Это необходимо, потому что кэши отключены в режиме S3.

MSalters
источник
1
Не все могут / будут скопированы. Для структуры кэш-памяти Intel / x86: если у меня кэш-память 256 КБ и 1024 КБ, я могу прочитать адрес 0. Он будет сохранен в кэш-памяти в местоположении 0. Затем я смогу прочитать адрес 1 и он будет сохранен в кэше в местоположении 1 Однако если я прочитаю адрес из (256Kib + 1), он также будет храниться по адресу 1 в кеше. Кэш-память использует дополнительную (метку) SRAM, чтобы указать, какая из двух хранится. Это означает, что чтение из кратных размеру кэшей не будет работать хорошо. (Обратите внимание, что это будет редкая вещь и обычно может быть проигнорировано).
Hennes
Это проницательно! Зачем мне неуклюже складывать то, что я считаю важным, в кэш-память L3, если я могу позволить целой армии гениев определить оптимальную вещь и запрограммировать процессор для этой оптимальной вещи. Правильно?
Зигги
3

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

Будет ли это полезно, другой вопрос - это заблокирует ядро ​​в ОЗУ, но в то же время уменьшит эффективный размер кэша. Также могут быть побочные эффекты (такие как отключение кэширования для остальной части системы), которые замедляют процесс.

Марк Леманн
источник
2

"Можем ли мы запустить Linux в L3 Cache?"

Нет , это невозможно, поскольку кэш-память не имеет прямой / линейной адресации.
Из-за того, как кэш-память спроектирована, реестр счетчика программ ЦП (IP) не может указывать на местоположение в кэш-памяти.

Кэш ЦП имеет свою собственную «ассоциативность», и эта ассоциативность определяет способ, которым «нормальная» память «отображается» в кэш-памяти. Эта особенность кэш-памяти является одной из причин, по которой кэш-память так быстро работает.

Максимум
источник
1

"Можем ли мы запустить Linux в L3 Cache?"

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

"мы можем запустить Linux в SRAM?"

Конечно, вы можете использовать SRAM с резервным питанием от батареи в качестве загрузочного раздела, тогда вы можете использовать встроенный флаг выполнения на месте. Это может привести к более быстрому времени загрузки и немного более быстрым операциям. Однако основным фактором является пропускная способность между кэшем L3 и тем, где находится ядро ​​(загрузочный диск или ОЗУ).

"Есть ли что-нибудь быстрее? Как быстро мы можем linux !?"

Как правило, производители оборудования и разработчики операционных систем работают над тем, чтобы сделать обработку максимально быстрой. Однако ваш вопрос носит очень общий характер: хотите ли вы ускорить загрузку, оптимизировать доступ к файловой системе, ускорить вычисления или что-то еще. Если у вас есть более конкретный вопрос, вы, безусловно, можете начать находить узкое место и устранять его. Ваш накопитель SRAM наверняка ускорит процесс загрузки. Добраться до GUI за 3 секунды было бы очень круто.

Фил Ханнент
источник
1

Когда-то во времена 486-х годов были машины, где вся оперативная память была SRAM. Это вернулось, когда 8 МБ было много, но, похоже, соответствует вашим ограничениям. Я уверен, что 8 МБ SRAM намного дешевле, чем тогда.

Таким образом, вы можете запустить Linux в SRAM, если машина сделана таким образом. Это не теоретическое; это было сделано.

Но не в кеше. Кэш подключен по-разному, и, что более важно, адрес по-разному. Вы не можете обратиться к этому же. Чанки отображаются по-разному, а не как непрерывный чанк. И содержимое не обязательно соответствует тому, что вы видите на диске - новые чипы Intel выполняют своего рода «своевременную компиляцию» (скорее перекодирование CISC => RISC-микроопераций), где микрооперации - это самое главное. что в конечном итоге в кеше. Короче говоря, то, что находится в кеше, - это не ваша программа, а измененное представление о ней, поэтому вы больше не можете использовать ее в качестве представления вашей программы в памяти.

Вопрос в том, почему. Помимо «потому что я могу», для этого не так много причин. Система Cache дает вам большую часть выигрыша в скорости с гораздо меньшими затратами. И помните, что стоимость не просто доллары ... SRAM требует больше транзисторов, что означает больше электричества.

Рич Гомолка
источник