Можем ли мы запустить Linux в чем-то быстрее, чем ОЗУ?
Это, возможно, глупый вопрос, и может быть результатом недоразумения. Я сейчас изучаю процессоры и память в частности. Я просто читал о том, насколько быстрее SRAM, чем DRAM, но дороже. SRAM очень дорогой: я немного покупал и нашел SRAM-карту с батарейным питанием на 16 МБ примерно за 400 долларов.
Недавно мой друг упомянул, что он запускает Puppy Linux в оперативной памяти, и что это быстро. Я заметил, однако, что крошечное ядро Linux может быть даже меньше... до 8 МБ! Это заставило меня задуматься: можем ли мы запустить Linux в SRAM? Этот вопрос даже правильно сформулирован?
Googling this question proved ineffective, but it raised yet more questions. Could one run linux in L3 Cache? Intel Core i7 can have an L3 Cache big enough to fit the 8MB... but am I making a categorical error? What is the difference between this and 'embedded' linux?
That's the question: can we run linux in SRAM or L3 Cache? Is there anything faster? How fast can we linux!?
г.
7 ответов
Linux или любая другая ОС не знает, как работает RAM. До тех пор, пока контроллер памяти настроен правильно (например, частота обновления установлена для не-SRAM), ОС не заботится о том, работает ли она на простой динамической памяти (обычное ОЗУ), оперативной памяти в режиме страничного режима (FP RAM, из C64-ish). раз), расширенный ОЗУ в режиме вывода данных (EDO), синхронное ОЗУ (SDRAM), любой из SDRAMS с двойной скоростью передачи данных (DDR 1/2/3) и т. д.
Все они поддерживают чтение и запись из разных мест. Все будет работать.
Теперь кеш немного другой. Вам не нужно писать в него, чтобы содержимое изменилось. Это будет мешать. Тем не менее, это несколько полезно. Я знаю, что coreboot использует кеш как своего рода память во время загрузки, прежде чем контроллер памяти будет правильно настроен. (Для получения подробной информации, посмотрите видео с выступлений coreboot во время FOSDEM 2011).
Так что в теории да, вы можете использовать это.
НО : для практических задач система с "обычной" "средней" памятью объемом 1 ГБ будет работать намного лучше, чем с очень быстрой памятью всего в несколько МБ. Это означает, что у вас есть три варианта:
- Стройте вещи обычным "дешевым" способом. Если вам нужна большая скорость, добавьте несколько десятков дополнительных компьютеров (все с "медленной" памятью)
- Или собрать один компьютер, цена которого будет в десятки раз выше, а производительность будет в десятки раз меньше.
За исключением очень редких случаев, последнее не имеет смысла.
Да, вы можете, и это на самом деле, как это уже сделано, автоматически. Наиболее часто используемые части оперативной памяти копируются в кэш. Если ваше общее использование оперативной памяти меньше размера кэша (как вы предполагаете), существующий механизм кэширования скопирует все в оперативную память.
Единственный момент, когда кэш-память затем копируется обратно в обычную оперативную память, - это когда ПК переходит в режим ожидания S3. Это необходимо, потому что кэши отключены в режиме S3.
Многие процессоры позволяют использовать кэш в качестве оперативной памяти. Например, большинство новых процессоров x86 могут конфигурировать определенные регионы как обратную запись с чтением без заполнения при чтении через MTRR. Это может использоваться для обозначения области адресного пространства как - эффективно - кеш-памяти.
Будет ли это полезно, другой вопрос - это заблокирует ядро в ОЗУ, но в то же время уменьшит эффективный размер кэша. Также могут быть побочные эффекты (такие как отключение кэширования для остальной части системы), которые замедляют процесс.
В x86 есть функция под названием CAR (кэш как RAM), которая позволяет вам писать «голый» код, такой как загрузчики или процедуры BIOS, на языке высокого уровня, таком как C, вместо ассемблера. Многие другие архитектуры могут иметь ту же функцию.
Таким образом, некоторые ОС могут полностью работать в кеше . Представьте себе, что у вас есть процессор Ryzen™ Threadripper™ 3990X с общим объемом кэш-памяти 292 МБ. Этого более чем достаточно для запуска даже современного крошечного Linux. Я думаю, вам потребуются значительные изменения в ядре Linux, чтобы оно заработало, но это определенно возможно.
Для получения дополнительной информации читайте
- Платформа для использования кэша процессора в качестве оперативной памяти (CAR)
- CAR: использование кэша в качестве оперативной памяти в LinuxBIOS
- Может ли процессор функционировать, используя только источник питания и ПЗУ, используя в качестве ОЗУ только внутренний кэш?
- Cache-as-Ram (без режима заполнения) Исполняемый код
- Для чего нужна инструкция INVD?
- Как BIOS инициализирует DRAM?
Когда-то во времена 486-х годов были машины, где вся оперативная память была SRAM. Это вернулось, когда 8 МБ было много, но, похоже, соответствует вашим ограничениям. Я уверен, что 8 МБ SRAM намного дешевле, чем тогда.
Таким образом, вы можете запустить Linux в SRAM, если машина сделана таким образом. Это не теоретическое; это было сделано.
Но не в кеше. Кэш подключен по-разному, и что более важно, по-разному. Вы не можете обратиться к этому же. Чанки отображаются по-разному, а не как непрерывный чанк. И содержимое не обязательно соответствует тому, что вы видите на диске - новые чипы Intel выполняют своего рода "своевременную компиляцию" (скорее перекодирование CISC=>RISC-микроопераций), где микрооперации - это самое главное. что в конечном итоге в кеше. Короче говоря, то, что находится в кеше, - это не ваша программа, а измененное представление о ней, поэтому вы больше не можете использовать ее в качестве представления вашей программы в памяти.
Вопрос в том, почему. Помимо "потому что я могу", для этого не так много причин. Система Cache дает вам большую часть выигрыша в скорости с гораздо меньшими затратами. И помните, что стоимость не просто доллары... SRAM требует больше транзисторов, что означает больше электричества.
"can we run linux in L3 Cache?"
No, Cache is there for a specific job of holding program data and instructions ready for when the processor is going to need them. You'll find the operating system in the cache anyway because its constantly being used. Loading all the OS into cache isn't efficient since you are not using every code path in the kernel at once.
"can we run linux in SRAM?"
Certainly you could use battery backed SRAM as your boot partition, you could then used the embedded flag of execute in place. That might lead to faster boot times and slightly faster operations. However a major factor is the bandwidth between the L3 Cache and where the kernel is (a boot drive or RAM).
"Is there anything faster? How fast can we linux!?"
Как правило, производители оборудования и разработчики операционных систем работают над тем, чтобы сделать обработку максимально быстрой. Однако ваш вопрос носит очень общий характер: хотите ли вы ускорить загрузку, оптимизировать доступ к файловой системе, ускорить вычисления или что-то еще. Если у вас есть более конкретный вопрос, вы, безусловно, можете начать находить узкое место и устранять его. Ваш накопитель SRAM наверняка ускорит процесс загрузки. Добраться до GUI за 3 секунды было бы очень круто.
"Можем ли мы запустить Linux в L3 Cache?"
Нет, это невозможно, поскольку кэш-память не имеет прямой / линейной адресации.
Из-за того, как кэш-память спроектирована, реестр счетчика программ ЦП (IP) не может указывать на местоположение в кэш-памяти.
Кэш ЦП имеет свою собственную "ассоциативность", и эта ассоциативность определяет способ, которым "нормальная" память "отображается" в кэш-памяти. Эта особенность кэш-памяти является одной из причин, по которой кэш-память так быстро работает.