1. Кэш - это не костыль, он избавляет от лишних обращений к диску. Особенно sys-кэш, хранящий прочитанные метаданные и папки. Кроме того, кэш гарантирует, что переданный буфер корректен, имеет выделенную физическую память, которая не исчезнет в процессе чтения из-за того, что другой поток решил освободить память.
2. Не нужно из 100%-й загрузки CPU делать вывод, что он тратит много времени на кэш. CPU занят пустым циклом в функции wait_for_sector_dma_ide* - артефакты отсутствия контроля над планировщиком Menuet. Если хочешь исправить 100%-ю загрузку - посмотри, как сделано в drivers/usb/usbstor.asm - disk_read_write, подающая команду, и read_write_callback, вызываемая при обработке команды. На скорость конкретно работы с диском это не влияет.
3. Линейно смотреть по 4K - быстро.
4. При чтении/записи из кэша буфер совершенно необязательно находится внутри кэша. Если код поддержки кэша видит, что сектор 123 находится на позиции 321, а сектор 124 - на позиции 22, то запрос будет на 2 сектора и пойдёт через промежуточный буфер, данные из которого код поддержки кэша сам раскидает куда надо.
5. IDE DMA контроллер умеет scatter/gather - таблица дескрипторов может быть длиннее одного дескриптора, её конец определяется по установленному старшему биту второго dword'а.
6. Один дескриптор для IDE DMA контроллера, судя по документации, не может пересекать границу 64K - буфер, начинающийся с 0xA987F000, придётся резать на первые 0x1000 байт и остальные. Так что даже для физически непрерывного буфера может понадобиться более одного дескриптора.
Скорость работы с IDE дисками
-
Сделаем мир лучше!
CleverMouse
А сейчас возможна ситуация, что буфер при вызовах DISKFUNC.read/write не будет непрерывным физически ?
А сейчас возможна ситуация, что буфер при вызовах DISKFUNC.read/write не будет непрерывным физически ?
Serge, да, там kernel_alloc для промежуточного буфера, который может и не быть непрерывным физически.
Сделаем мир лучше!
CleverMouse
Непрерывен, если размер кратен 8. Вот гарантировать выравнивание сложнее. Видимо всё драйвер должен отслеживать порядок страниц и границы 64К.
Непрерывен, если размер кратен 8. Вот гарантировать выравнивание сложнее. Видимо всё драйвер должен отслеживать порядок страниц и границы 64К.
Размер необязательно кратен 8. Запись 18 секторов, которую не получилось сделать из кэша напрямую, пойдёт через буфер на две страницы.
Сделаем мир лучше!
Ладно, начнём с PIO, раз уж он есть. Отключил DMA, старые вызовы fs работали нормально, новые вешали систему сразу после успешного копирования, то-есть несколько чтений, несколько записей, disk_synk, зависание. После перехода на FFFF секторов стало только хуже. Но возможно проблема не в драйвере, а в кешировании; в любом случае, я почти не знаю, как оно работает, чего ожидает и какие там ещё уровни. CleverMouse?
В новом hd_drv.inc я сходу никаких проблем не вижу, кроме разве что безусловного LBA48 без предварительной проверки, что он вообще поддерживается.
"Старые" и "новые" - это fs_read32*/fs_write32* и fs_read64*/fs_write64* соответственно? Если да, то давай код с fs_read64*/fs_write64*, надо разбираться.
"Старые" и "новые" - это fs_read32*/fs_write32* и fs_read64*/fs_write64* соответственно? Если да, то давай код с fs_read64*/fs_write64*, надо разбираться.
Сделаем мир лучше!
А там и не было проверки, LBA48 использовалось если адрес не влазил в 28 бит. А в LBA28 только один байт под количество, сильно замедлит младшие сектора.
Сейчас зависает почти сразу же. Мне кажется, что в теме "KolibriOS freezes while accessing hdd" та же проблема - наверно никто не проверял, как кеширование работает с PIO.
В крайнем случае можно сделать disk_cache.inc с отключённым кешированием.
Сейчас зависает почти сразу же. Мне кажется, что в теме "KolibriOS freezes while accessing hdd" та же проблема - наверно никто не проверял, как кеширование работает с PIO.
В крайнем случае можно сделать disk_cache.inc с отключённым кешированием.
Кэширование можно отключить на уровне драйвера устройства, прописать ramdisk_adjust_cache_size последним элементом в структуру функций драйвера, не залезая в disk_cache.inc.
Я позже посмотрю, в чём дело.
Я позже посмотрю, в чём дело.
Сделаем мир лучше!
Если на диске вообще есть адреса, не влезающие в 28 бит, то и LBA48 там быть должен. Так что на текущее поведение не кивай.
Под Bochs не зависает. По симптомам похоже на interrupt storm, когда диск генерирует прерывание, обработчик ничего не делает, прерывание возникает снова и снова. Для начала проверки можно раскомментировать первые строчки с DEBUGF в IDE_irq_14_handler, IDE_irq_15_handler, IDE_common_irq_handler и загрузиться с дублированием отладочного вывода прямо на экран - если в момент зависания повторяющиеся строчки заполнят экран, проблема в этом.
Под Bochs не зависает. По симптомам похоже на interrupt storm, когда диск генерирует прерывание, обработчик ничего не делает, прерывание возникает снова и снова. Для начала проверки можно раскомментировать первые строчки с DEBUGF в IDE_irq_14_handler, IDE_irq_15_handler, IDE_common_irq_handler и загрузиться с дублированием отладочного вывода прямо на экран - если в момент зависания повторяющиеся строчки заполнят экран, проблема в этом.
Сделаем мир лучше!
Проблема в обратном: при обращении к младшим секторам всегда будет использоваться LBA28, что означает падение скорости в несколько раз по текущей причине.
А если да, то что тогда делать?
Мой hd_drv.inc? Совсем весело... Я же не использую DMA, откуда прерывания?Под Bochs не зависает
А если да, то что тогда делать?
PIO тоже генерирует прерывания.
Serge, может всё-таки по-подробней? Я когда свой драйвер писал, прерываниями не пользовался. И сейчас ничего не удалял, выходит они и раньше не обрабатывались.
Да, interrupt storm, но судя по "Preempting/Preventing IRQs from firing", может не получится их уверенно отключить - сейчас вроде используется Regular Status port. Но их можно и обрабатывать. Что лучше?
Who is online
Users browsing this forum: No registered users and 2 guests