@ru @rf

Почему до сих пор не существует постоянных накопителей, замапленных (аппаратно, как DRAM, как MMIO, как BIOS SPI на x86) в основное адресное пространство?

@nekun Существует, конечно же. На многих ARM SoC контроллер NAND-флеши её отображает в адресное пространство. Linux даже умеет XIP с таких девайсов.
@ru @rf

Follow

@L29Ah @ru @rf

Почему же это не применяется не в эмбеде, и вместо поддержки аппаратного маппинга SSD больших объёмов в чипсетах x86 мы получили NVMe, со всё той же моделью доступа для медленных носителей, c DMA, со сложными драйверами, со сложным слоем mm/fscache в ядре?

напр., унифицированный слой wear leveling + трансляция в main memory и слоты расширения с тупыми чипами как DIMM

@nekun Например потому что там ебучие пайплайны повсюду, задержки большие в сравнении с циклом цпу а останавливать ядро подождать пока страница загрузится из NAND в RAM-кеш это некруто, пусть лучше yield'нется на другую задачу.
Вообще вроде есть low latency флеш в форме DRAM-модулей, по крайней мере я помню что интел что-то подобное выпускал, зацени.
@ru @rf

@nekun Ага.
@pomstan@срёт.онлайн @rf

@L29Ah @ru @rf

Ну допустим ядро процессора заблокируется на инструкции чтения некэшированных данных: если зависнет надолго, таймер разбудит планировщик, и ядро сможет переключиться на другую задачу, пока контроллер спокойно параллельно занимается выгрузкой, не занимая CPU. С другой стороны, при классическом доступе адрес пройдёт через TLB, вызовется , критическая секция, потом тысячи тактов логики nvme драйвера пока он не сформирует DMA-запрос, и только потом уже можно свитчиться.

// чё будет если прерывание настигло посреди инструкции с memory операндом?

Sign in to participate in the conversation
Qoto Mastodon

QOTO: Question Others to Teach Ourselves
An inclusive, Academic Freedom, instance
All cultures welcome.
Hate speech and harassment strictly forbidden.