Page 2 of 10

Re: NTFS

Posted: Mon May 18, 2015 4:03 pm
by CleverMouse
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 байт и остальные. Так что даже для физически непрерывного буфера может понадобиться более одного дескриптора.

Re: NTFS

Posted: Mon May 18, 2015 4:24 pm
by Serge
CleverMouse
А сейчас возможна ситуация, что буфер при вызовах DISKFUNC.read/write не будет непрерывным физически ?

Re: NTFS

Posted: Mon May 18, 2015 4:35 pm
by CleverMouse
Serge, да, там kernel_alloc для промежуточного буфера, который может и не быть непрерывным физически.

Re: NTFS

Posted: Mon May 18, 2015 9:09 pm
by Serge
CleverMouse
Непрерывен, если размер кратен 8. Вот гарантировать выравнивание сложнее. Видимо всё драйвер должен отслеживать порядок страниц и границы 64К.

Re: NTFS

Posted: Mon May 18, 2015 9:25 pm
by CleverMouse
Размер необязательно кратен 8. Запись 18 секторов, которую не получилось сделать из кэша напрямую, пойдёт через буфер на две страницы.

Re: Скорость работы с IDE дисками

Posted: Wed May 20, 2015 4:42 am
by Pathoswithin
Ладно, начнём с PIO, раз уж он есть. Отключил DMA, старые вызовы fs работали нормально, новые вешали систему сразу после успешного копирования, то-есть несколько чтений, несколько записей, disk_synk, зависание. После перехода на FFFF секторов стало только хуже. Но возможно проблема не в драйвере, а в кешировании; в любом случае, я почти не знаю, как оно работает, чего ожидает и какие там ещё уровни. CleverMouse?

Re: Скорость работы с IDE дисками

Posted: Wed May 20, 2015 3:58 pm
by CleverMouse
В новом hd_drv.inc я сходу никаких проблем не вижу, кроме разве что безусловного LBA48 без предварительной проверки, что он вообще поддерживается.
"Старые" и "новые" - это fs_read32*/fs_write32* и fs_read64*/fs_write64* соответственно? Если да, то давай код с fs_read64*/fs_write64*, надо разбираться.

Re: Скорость работы с IDE дисками

Posted: Wed May 20, 2015 5:36 pm
by Pathoswithin
А там и не было проверки, LBA48 использовалось если адрес не влазил в 28 бит. А в LBA28 только один байт под количество, сильно замедлит младшие сектора.
Сейчас зависает почти сразу же. Мне кажется, что в теме "KolibriOS freezes while accessing hdd" та же проблема - наверно никто не проверял, как кеширование работает с PIO.
В крайнем случае можно сделать disk_cache.inc с отключённым кешированием.

Re: Скорость работы с IDE дисками

Posted: Wed May 20, 2015 5:42 pm
by CleverMouse
Кэширование можно отключить на уровне драйвера устройства, прописать ramdisk_adjust_cache_size последним элементом в структуру функций драйвера, не залезая в disk_cache.inc.

Я позже посмотрю, в чём дело.

Re: Скорость работы с IDE дисками

Posted: Wed May 20, 2015 8:16 pm
by CleverMouse
Если на диске вообще есть адреса, не влезающие в 28 бит, то и LBA48 там быть должен. Так что на текущее поведение не кивай.

Под Bochs не зависает. По симптомам похоже на interrupt storm, когда диск генерирует прерывание, обработчик ничего не делает, прерывание возникает снова и снова. Для начала проверки можно раскомментировать первые строчки с DEBUGF в IDE_irq_14_handler, IDE_irq_15_handler, IDE_common_irq_handler и загрузиться с дублированием отладочного вывода прямо на экран - если в момент зависания повторяющиеся строчки заполнят экран, проблема в этом.

Re: Скорость работы с IDE дисками

Posted: Wed May 20, 2015 10:58 pm
by Pathoswithin
Проблема в обратном: при обращении к младшим секторам всегда будет использоваться LBA28, что означает падение скорости в несколько раз по текущей причине.
Под Bochs не зависает
Мой hd_drv.inc? Совсем весело... Я же не использую DMA, откуда прерывания?
А если да, то что тогда делать?

Re: Скорость работы с IDE дисками

Posted: Wed May 20, 2015 11:21 pm
by Serge
PIO тоже генерирует прерывания.

Re: Скорость работы с IDE дисками

Posted: Wed May 20, 2015 11:39 pm
by Pathoswithin
Serge, может всё-таки по-подробней? Я когда свой драйвер писал, прерываниями не пользовался. И сейчас ничего не удалял, выходит они и раньше не обрабатывались.

Re: Скорость работы с IDE дисками

Posted: Thu May 21, 2015 9:36 am
by Serge

Re: Скорость работы с IDE дисками

Posted: Thu May 21, 2015 7:48 pm
by Pathoswithin
Да, interrupt storm, но судя по "Preempting/Preventing IRQs from firing", может не получится их уверенно отключить - сейчас вроде используется Regular Status port. Но их можно и обрабатывать. Что лучше?