LINUX.ORG.RU

Буферы и дисковые кеши

 , , ,


0

3

Привет, all! Допустим, есть одна getc из стандартной библиотеки. Как мы знаем, внутри она использует буфер, таким образом, последовательно её вызывая не происходит многократных переключений контекста ядро - приложение. Я все правильно понимаю?

Но вот беда. Любое приложение несет свой кеш, вместо, например, использования общесистемного дискового кеша. А в каком-нибудь minix можно было бы полагаться на дисковый кеш, избегая переключений контекста.

Либо можно сделать какой-то хитрый инвалидируемый буфер чтения в libc, разделяемый между приложениями.

Какие варианты используют в современных операционных системах?



Последнее исправление: anon1984 (всего исправлений: 1)

Ответ на: комментарий от anon1984

Как микроядро связано с разделяемыми буферами?

Что такое общесистемный дисковый кеш в плане чтения из сокета/пайпа/терминала?

нужно использовать mmap. Правда хз что там с инвалидацией.

Ну дак изучите mmap.

mky ★★★★★
()
Ответ на: комментарий от anon1984

mmap будет разделяемым между разными процессами, но если процесс всего один и файл ещё не успел попасть в кеш то mmap заметно медленнее чем read() большими блоками - mmap читает мелкими.

firkax ★★★★★
()

А в каком-нибудь minix можно было бы полагаться на дисковый кеш, избегая переключений контекста.

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

инвалидируемый буфер чтения в libc, разделяемый между приложениями

Если ты читаешь с блочного устройства оно и так за-mmap-ится неявно. Страничный mmap кэш сейчас заменяет дидовский дисковый кэш.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Если ты читаешь с блочного устройства оно и так за-mmap-ится неявно. Страничный mmap кэш сейчас заменяет дидовский дисковый кэш.

Лор торт, спасибо.

anon1984
() автор топика