Почему же это не применяется не в эмбеде, и вместо поддержки аппаратного маппинга SSD больших объёмов в чипсетах x86 мы получили NVMe, со всё той же моделью доступа для медленных носителей, c DMA, со сложными драйверами, со сложным слоем mm/fscache в ядре?
напр., унифицированный слой wear leveling + трансляция в main memory и слоты расширения с тупыми чипами как DIMM
@nekun Например потому что там ебучие пайплайны повсюду, задержки большие в сравнении с циклом цпу а останавливать ядро подождать пока страница загрузится из NAND в RAM-кеш это некруто, пусть лучше yield'нется на другую задачу.
Вообще вроде есть low latency флеш в форме DRAM-модулей, по крайней мере я помню что интел что-то подобное выпускал, зацени.
@ru @rf
Ну допустим ядро процессора заблокируется на инструкции чтения некэшированных данных: если зависнет надолго, таймер разбудит планировщик, и ядро сможет переключиться на другую задачу, пока контроллер спокойно параллельно занимается выгрузкой, не занимая CPU. С другой стороны, при классическом доступе адрес пройдёт через TLB, вызовется #PF, критическая секция, потом тысячи тактов логики nvme драйвера пока он не сформирует DMA-запрос, и только потом уже можно свитчиться.
// чё будет если прерывание настигло посреди инструкции с memory операндом?
@nekun@qoto.org @ru@lor.sh @rf@mastodon.ml Это имеет смысл в двух случаях:
1. время доступа к устройству меньше, чем программная подгрузка;
2. доступ нужен до (или без) загрузки драйвера.
Если время доступа больше чем нужно драйверу и переключению контекста, то железка просто будет останавливать процессор, вместо того, чтобы он переключился на другую задачу, пока текущая ждёт ввода-вывода. Это было бы просто потерей производительности.
А если накопитель ещё и внешний, и его отсоединили, то комп или зависнет намертво, или работавшая с ним задача грохнется с аппаратным исключением (если это реализовано).
Так то флэш часто отображается в память, например, на ARM-ах.
Я ещё добавил бы такие доводы:
1. Уменьшение кодовой базы операционных систем, а следовательно и человеческих затрат, и багов.
2. Унификация wear-leveling слоя в стандартном контроллере чипсета.
Кстати, кажется, из этих соображений от программно-управляемых NAND пришли к eMMC и UFS.
> Если время доступа больше чем нужно драйверу и переключению контекста, то железка просто будет останавливать процессор, вместо того, чтобы он переключился на другую задачу, пока текущая ждёт ввода-вывода.
Ну, он ещё по таймеру может переключиться на шедулер, впрочем я не имею понятия, ждут ли прерывания завершения инструкции (возможно, заимплементить специальный класс адресов в MTRR?)
Причём, такие задержки также можно минимизировать WB-кэшем контроллера.
> А если накопитель ещё и внешний, и его отсоединили, то комп или зависнет намертво, или работавшая с ним задача грохнется с аппаратным исключением (если это реализовано).
Контроллер прерывание пошлёт и драйвер обработает: а собственно что ещё делать задаче, пытающейся достать мапнутый недоступный физически файл, кроме как сегфолтиться? ну а через fd и ОС ошибку дать может, всё штатненько
1. Уменьшение кодовой базы ОС настолько же, насколько увеличение сложности железа. Усложнять железо дороже. Но да, если такое возможно малой кровью — делают, например, в случае с флэшем.
2. Унификация обычно делается на уровне интерфейса (SATA, USB вот это всё). Если контроллер интерфейса будет уметь отображать носитель в память — такое будет работать.
Но это не универсальное решение — в отображении есть смысл, если адресное пространство носителя (носителей) меньше, чем у процессора. Но оно может быстро исчерпаться.
Насчёт переключения по таймеру.
Тут всё будет зависеть от того, как реализована работа с памятью в процессоре и на шине. Для того, чтобы прерваться, нужно, чтобы
— процессов поддерживал отмену цикла шины с будущим повтором (abort&retry);
— системный контроллер поддерживал abort шины по таймауту;
— контроллер носителя также поддерживал такой режим;
— ОС умела отличать остановку по неготовности устройства от какой-нибудь ошибки (обращение к несуществующему устройству например);
Из-за того, что в аппаратной реализации такого куча нюансов, обычно стараются сложную логику вынести в софт.
@nekun@qoto.org @rf@mastodon.ml @ru@lor.sh Помимо обычных прерываний в процессорах обычно есть другие аппаратные исключения (Hardware exception), в том числе отвечают за всякие ужасы на шине, segfault один из них, который вырабатывается MMU. Ещё бывает bus fault, который вырабатывается если обращение не может быть обработано внешним устройством.
Прерывание от таймера это как правило обычное прерывание, а прерывания обычно обрабатываются по завершению инструкции. То есть обычный таймер не поможет: процессору сначала придётся дождаться конца цикла шины, а потом только заняться таймером.
Для целей отмены таких долгих обращений нужно использовать исключение шины (bus fault или что-то подобное): если цикл обращения затянулся слишком долго — обрывать его и делать повтор позже.
@nekun Существует, конечно же. На многих ARM SoC контроллер NAND-флеши её отображает в адресное пространство. Linux даже умеет XIP с таких девайсов.
@ru @rf