Буферизация ввода/вывода

[ilovb]

Но я в принципе согласен что в современных осях производительности системного кэширования достаточно для большинства задач. Свой буфер имеет смысл делать только в экстремальных задачах.

[ilovb]

Так там тоже вроде как через int 21h это делается. Нет? То есть через прерывание - а это медленно. Это рраз.
Два - системный буфер в ДОС-е тоже есть (как бишь эту системную стандартную утиль звали, которая его включает... не помню, надо же... А! Во! smartdrv)

Не шарю в тонкостях IO DOS. Но в TP вроде был свой буфер, и читалось/писалось из него прямо на диск (а не в какой-то системный буфер). И потому в TP блочный ввод вывод с буфером кратным размеру сектора давал ускорение на порядки за счет минимизации числа обращений к диску. То же самое в оригинальном Обероне.

[ilovb]

Кроме того если ты не контролируешь буфер, то скорее всего будут проблемы при реализации транзакций например, ибо неизвестно на диске уже данные или нет.

[valexey_u]

Так там тоже вроде как через int 21h это делается. Нет? То есть через прерывание - а это медленно. Это рраз.
Два - системный буфер в ДОС-е тоже есть (как бишь эту системную стандартную утиль звали, которая его включает... не помню, надо же... А! Во! smartdrv)

Не шарю в тонкостях IO DOS. Но в TP вроде был свой буфер, и читалось/писалось из него прямо на диск (а не в какой-то системный буфер). И потому в TP блочный ввод вывод с буфером кратным размеру сектора давал ускорение на порядки за счет минимизации числа обращений к диску. То же самое в оригинальном Обероне.

А вот если запустить до того smartdrv, то разница будет уже не столь велика :-) То есть экономия будет просто за счет меньшего числа прерываний.

[ilovb]

Ради интереса посмотрел размеры буферов в разных Оберонах:
1. А2 - 4 КБ
2. ETH Oberon - 4 КБ
3. Linz Oberon V4 - 1 КБ
4. оригинальный Oberon:

Код: [Выделить]

BufferRecord =
RECORD apos, lim: INTEGER;
   mod: BOOLEAN;
   next: Buffer;
   data: FileDir.DataSector;
END

где:
DataSector = RECORD(Kernel.Sector)
    B: ARRAY SectorSize OF SYSTEM.BYTE;
END

где:
SectorSize = 1024


[valexey_u]

Охохо. По моему, у нас тут идет смешение теплого с мягким.

Если мы пишем ОС, или работаем с блочным устройством на прямую, то критерии выбора размера буфера будет одни (будем подстраиваться под устройство оного блочного устройства).

Если мы пишем прикладное ПО, работающее на ОС у которой есть свой буфер, то критерии выбора размера буфера будут уже совсем другие. Ибо это буфер взаимодействия с ОС, а не буфер взаимодействия с блочным устройством.

Внимание вопрос - какой случай нас интересует?

[ilovb]

Тык вот именно! Я это и пытаюсь понять. Во всех приведенных системах размер буфера выбран конкретного размера по объективным причинам, ибо все эти системы могут работать нативно. И там это дает существенный профит.

А вот почему буфер ББ такой непонятно. И непонятно почему он фиксированный. Кроме того буфер ББ - это не то же самое, что буфер Оберона, т.к. нет прямого обмена с файловой системой. Т.е. в ББ буфер пользовательский и его размер по идее не зависит от файловой системы. Системный буфер windows делает за ББ ту работу, которая лежала на буфере оригинального Оберона.

[ilovb]

И кроме того, valexey, управление файлами и буферами во всех Оберонах одинаковое. В этом то и странность.

ps А системный буфер windows вообще 256КБ...

[valexey_u]

И кроме того, valexey, управление файлами и буферами во всех Оберонах одинаковое. В этом то и странность.

ps А системный буфер windows вообще 256КБ...

Да ладно? А это что такое?

[ilovb]

Это весь кэш. А я говорю про отдельный буфер:

As depicted by the solid arrows in the previous figure, a 256 KB region of data is read into a 256 KB cache "slot" in system address space when it is first requested by the cache manager during a file read operation. A user-mode process then copies the data in this slot to its own address space. When the process has completed its data access, it writes the altered data back to the same slot in the system cache, as shown by the dotted arrow between the process address space and the system cache. When the cache manager has determined that the data will no longer be needed for a certain amount of time, it writes the altered data back to the file on the disk, as shown by the dotted arrow between the system cache and the disk.

http://msdn.microsoft.com/ru-ru/library/windows/desktop/aa364218(v=vs.85).aspx

[ilovb]

По аналогии - в ББ весь кэш 8 КБ на каждый файл, т.к. состоит из 4 буферов по 2 КБ

[valexey_u]

И кроме того, valexey, управление файлами и буферами во всех Оберонах одинаковое. В этом то и странность.

Ну, а что такого странного? Что 1024 что 4096 буфер будет работать лучше чем без буфера вообще (в случае если мы работаем поверх ОС). Впрочем, также неплохо будет работать и буфер размером в 1234 байта (но немного хуже, но чтобы это самое немного хуже обнаружить, придется сильно извратиться). Ибо экономим на syscall'ах. То есть выбор не принципиален для очень многих задач.

[ilovb]

Странно что он такой маленький и фиксированный.
Размер 2 КБ ни туда ни сюда. Не оставили же они 1 КБ как в оригинале...

[ilovb]

Т.е. для уменьшения частоты обмена с системным буфером логичнее было бы делать пользовательский буфер больше (32КБ - 64КБ), но они этого не сделали, и даже сделали размер неизменным...

[valexey_u]

Странно что он такой маленький и фиксированный.
Размер 2 КБ ни туда ни сюда. Не оставили же они 1 КБ как в оригинале...

Изучая исключительно io-шедулер NT ты не поймешь почему в ББ сделано именно так. Просто потому, что ББ не затачивался под NT.

ББ затачивался под Win9x и MacOS (классику). Поэтому, видимо, следует смотреть что было с кешированием там, и что там было с FS.

То есть решение по этой константе было принято когда-то тогда. Решение не менялось просто потому, что ни разу не встретилась задача, где это выстрелило бы.