Сравнение производительности файловых систем или Reiser4 наносит ответный удар.

>> Да, для mmap подходит, для файлового дескриптора - нет, fsync и прочие сбрасывают все страницы. И это опять дополнительные накладные расходы.

>чего? msync() сбрасывает только нужные страницы. какие еще накладные расходы?

Перечитайте еще раз, что написано выше. А затем еще несколько раз до полного просветления.

>> Ваша ирония не к месту.

>до тех пор пока не объясните - очень даже к месту.

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

Залоченную страницу нельзы выкинуть по той простой причине, что pg_locked бит используется как индикатор того, что страница используется, а следовательно вы не можете инвалидировать ее данные и/или сбросить их на диск, т.к. операция записи в страницу может быть не завершена.

>> Почитайте еще раз, о чем шла речь выше - readahead, вызванный fadvise(), запустит swapper/bdflush, которые выкинут из кэша чужие страницы, следующий readahead - для другого файла, выкинет страницы первого (в своп или на диск).

>бугога. а аллокация анонимных страниц, в которые потом будет класть directIO этого не вызовет? бугога.

Сравнили одну страницу и max_sane_readahead страниц - почувствуйте разницу.

> Плюс, вы разработчик reiserfs, что является не самой лучшей рекламой для этой системы.

ипанулись?

> Залоченную страницу нельзы выкинуть по той простой причине, что pg_locked бит используется как индикатор того, что страница используется, а следовательно вы не можете инвалидировать ее данные и/или сбросить их на диск, т.к. операция записи в страницу может быть не завершена.

да, нельзя. только рассказать забыли зачем она залочена. тупо перечитываем выше ... "msync() сбросит ее на диск, madvise() отмапит"

> Сравнили одну страницу и max_sane_readahead страниц - почувствуйте разницу.

используйте fadvase/madvise и почуствуйте разницу.

>> Так и зачем он нужен? Правильно, readahead не нужен. А page cache зачем в этой задаче случайной выборки страниц?

>затем, что это один универсальный механизм, а не корявый костыль direct IO. еще раз, анонимные страницы - это по-сути тот же pagecache, только backing device для него - swap, а не инода того файла, с которым работаем.

Данные читаются - читаются в пользовательский буфер. Он есть _всегда_, и для пользователя данной задачи - именно он будет буфером, а не дополнительная прослойка page cache, которая только съест память.

page cache добавляет производительность _только_, если данные будут в ближайшем времени прочитаны повторно. В случае огромных файлов и случайного доступа это условие не выполняется.

>> Сравнили одну страницу и max_sane_readahead страниц - почувствуйте разницу.

>используйте fadvase/madvise и почуствуйте разницу.

Начинаем снова? Это дополнительные накладные расходы, которые абсолютно не нужна в описываемой задаче. Мало того, что дополнительная память используется для page cache (даже для маленьких буферов), это еще и дополнительные проблемы для всей vfs (swap и *dflush) - и зачем? Когда пользовательские страницы будут содержать эти же данные и повторного чтения не будет?

> Данные читаются - читаются в пользовательский буфер. Он есть _всегда_, и для пользователя данной задачи - именно он будет буфером, а не дополнительная прослойка page cache, которая только съест память.

читать уже будешь наконец? пользовательские страницы, они же анонимные, работают через такие же страницы. и для них тоже есть маппинг. это как раз они работают поверх pagecache.

> page cache добавляет производительность _только_, если данные будут в ближайшем времени прочитаны повторно. В случае огромных файлов и случайного доступа это условие не выполняется.

он и не должен добавлять производительности. зачем directIO, если то же самое можно сделать через прямой и отлаженный механизм? в случае "огромных файлов" и других прочих этот механизм настраивается как нужно.

>> Плюс, вы разработчик reiserfs, что является не самой лучшей рекламой для этой системы.

>ипанулись?

Может быть я и не прав, но вы так активно вступились за reiser только после того, как указали на его потенциальные проблемы...

>> Залоченную страницу нельзы выкинуть по той простой причине, что pg_locked бит используется как индикатор того, что страница используется, а следовательно вы не можете инвалидировать ее данные и/или сбросить их на диск, т.к. операция записи в страницу может быть не завершена.

>да, нельзя. только рассказать забыли зачем она залочена. тупо перечитываем выше ... "msync() сбросит ее на диск, madvise() отмапит"

Вы не дочитали мое предложение до конца, пожалуйста, прочтите все целиком.

Кстати, пока спим в msync() добавить данные в файл в конец нельзя? mmap сделать нельзя?

И повторю - это работает только для замапленного файла, для обычного доступа через read/write - такого механизма нет.

> Начинаем снова? Это дополнительные накладные расходы, которые абсолютно не нужна в описываемой задаче. Мало того, что дополнительная память используется для page cache (даже для маленьких буферов), это еще и дополнительные проблемы для всей vfs (swap и *dflush) - и зачем? Когда пользовательские страницы будут содержать эти же данные и повторного чтения не будет?

угу. начинаем.

1) покажи где именно дополнительные расходы 2) где там дополнительная память? 3) какие там *дополнительные проблемы для всей vfs? 4) когда повторного чтения не будет - madvise/fadvize

при этом pagecache уже давно хорошо отлажен. а directIO до сих пор корявый костыль. которому еще и приходится консультироваться в pagecache дабы не было рейсов.

>> Данные читаются - читаются в пользовательский буфер. Он есть _всегда_, и для пользователя данной задачи - именно он будет буфером, а не дополнительная прослойка page cache, которая только съест память.

>читать уже будешь наконец? пользовательские страницы, они же анонимные, работают через такие же страницы. и для них тоже есть маппинг. это как раз они работают поверх pagecache.

Они есть _всегда_. т.к. с ними работает приложение. В случае page cache есть еще и он. Данные читаются из файла в пользовательский буфер всегда: либо из pagecache, либо напрямую.

>> page cache добавляет производительность _только_, если данные будут в ближайшем времени прочитаны повторно. В случае огромных файлов и случайного доступа это условие не выполняется.

>он и не должен добавлять производительности. зачем directIO, если то же самое можно сделать через прямой и отлаженный механизм? в случае "огромных файлов" и других прочих этот механизм настраивается как нужно.

Эти настройки - это дополнительные расходы, которые отлично обходятся в directio.

> Может быть я и не прав, но вы так активно вступились за reiser только после того, как указали на его потенциальные проблемы...

я слово reiser ни разу не упомянул.

> Вы не дочитали мое предложение до конца, пожалуйста, прочтите все целиком.

ага. про то, что анонимные страницы обходятся без pagecache? :)))

> Кстати, пока спим в msync() добавить данные в файл в конец нельзя? mmap сделать нельзя?

не нужно лжи.

> И повторю - это работает только для замапленного файла, для обычного доступа через read/write - такого механизма нет.

и кто же мешает вместо open(O_DIREC) сделать open, а потом mmap на нужный кусок?

> Они есть _всегда_. т.к. с ними работает приложение. В случае page cache есть еще и он. Данные читаются из файла в пользовательский буфер всегда: либо из pagecache, либо напрямую.

бугога. замапили страницы. они есть всегда. данные прочитаются прямо в них, никаког copy_to_user()

> Эти настройки - это дополнительные расходы, которые отлично обходятся в directio.

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

>1) покажи где именно дополнительные расходы 2) где там дополнительная память? 3) какие там *дополнительные проблемы для всей vfs? 4) когда повторного чтения не будет - madvise/fadvize

Пользовательское приложение читает данные в свою память, в анонимные страницы. Оно _всегда_ это делает (например по байту с каждой случайной страницы), дополнительные расходы возникают пр чтении данных в pagecache, при хранении их там, при поддержании всех деревьев, при работе свопа - дополнительные расходы из-за того, что есть еще и pagecache, который _не_ нужен в этой задаче.

>при этом pagecache уже давно хорошо отлажен. а directIO до сих пор корявый костыль. которому еще и приходится консультироваться в pagecache дабы не было рейсов.

В случае описанной задачи их нет.

P.S. я должен уходить, если возникнут вопросы, отвечу завтра.

> Ах, да, только то, что ей скажут

Не обязательно всем все говорить. Вы же не говорите каждый раз планировщику, какой будет процесс, интерактивный, или cpu-bound. Он худо-бедно научен, как их определять.

>А откуда заранее известно, насколько хорошо или плохо сжимаются те или иные данные?

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

и у меня вопрос;;;

> дополнительные проблемы для всей vfs (swap и *dflush)

какой своп? какой flush? если данные не менялись (чистое чтение) - ни того. ни другого не будет. Если менялись - их надо сбросить в backing store, и лучше пусть это сделают системные средства, у них с batching дела получше.

> Пользовательское приложение читает данные в свою память, в анонимные страницы. Оно _всегда_ это делает (например по байту с каждой случайной страницы), дополнительные расходы возникают пр чтении данных в pagecache, при хранении их там, при поддержании всех деревьев, при работе свопа - дополнительные расходы из-за того, что есть еще и pagecache, который _не_ нужен в этой задаче.

даже уже слов цензурных нет. mmap - это отображение страниц pagecache'а в пространство процесса. где здесь дополнительные расходы?

может быть хоть сейчас заметит ...

АНОНИМНЫЕ СТРАНИЦЫ РАБОТАЮТ ПОВЕРХ PAGECACHE АНОНИМНЫЕ СТРАНИЦЫ РАБОТАЮТ ПОВЕРХ PAGECACHE АНОНИМНЫЕ СТРАНИЦЫ РАБОТАЮТ ПОВЕРХ PAGECACHE

> В случае описанной задачи их нет.

есть. показать?

__blockdev_direct_IO() -> filemap_write_and_wait_range()

>даже уже слов цензурных нет. mmap - это отображение страниц pagecache'а в пространство процесса. где здесь дополнительные расходы?

>может быть хоть сейчас заметит ...

>АНОНИМНЫЕ СТРАНИЦЫ РАБОТАЮТ ПОВЕРХ PAGECACHE АНОНИМНЫЕ СТРАНИЦЫ РАБОТАЮТ ПОВЕРХ PAGECACHE АНОНИМНЫЕ СТРАНИЦЫ РАБОТАЮТ ПОВЕРХ PAGECACHE

Вы серьезно не понимаете, о чем идет речь?

Ситуация: вы читаете по байту из произвольной страницы. 4096 чтений. В результате занята _одна_ анонимная пользовательская страница.

В случае pagecache у вас есть 2 варианта:

1. fadvise, read, sync, fadvise для каждого чтения, итого в 4 раза увеличенные накладные расходы.

2. fadvice, read - будет прочитан один блок, который займет одну страницу в pagecache, итого для 4096 чтений в памяти будут 4096 страниц, которые будут выкидывать приложение в своп, откуда оно потом будет подниматься и т.п.

В случае directio - только read.

>> дополнительные проблемы для всей vfs (swap и *dflush)

>какой своп? какой flush? если данные не менялись (чистое чтение) - ни того. ни другого не будет. Если менялись - их надо сбросить в backing store, и лучше пусть это сделают системные средства, у них с batching дела получше.

Я выше привел пример с произвольным стением - либо 4х-кратное увеличение количества системных вызовов, либо многократное увеличение используемой памяти. Во втором случае включается своп, flush (если данные менялись).

pagecache полезен тогда и только тогда, когда вероятность повторного доступа к той же странице велика. В описанной задаче она мала, поэтому pagecache (только свои страницы, управляемые через fadvise, не весь pagecache) здесь только добавляет дополнительные расходы.

> Ситуация: вы читаете по байту из произвольной страницы. 4096 чтений. В результате занята _одна_ анонимная пользовательская страница.

за такое использование read'а и расположение данных нужно руки отрывать. еще расскажи как оракл читает по одному байту .. ага ...

> 1. fadvise, read, sync, fadvise для каждого чтения, итого в 4 раза увеличенные накладные расходы.

fadvise делается один раз, при открытии файла. read делается точно такой же, даже тем же ->readpage() sync не нужен, или чтение через mmap грязнит страницы? directIO будет делать проход по pgtable, чтобы пользовательские страницы залочить в памяти

> В случае directio - только read.

код для начала погляди, хотя бы

Более того, когда вы работаете с mmap, во время msync() вы не сможете ни читать данные (елси нужно делать дополнительный mmap(), а в нашем тесте это как раз нужно), ни изменять (запись в конец с увеличением размера).

> Я выше привел пример с произвольным стением - либо 4х-кратное увеличение количества системных вызовов, либо многократное увеличение используемой памяти. Во втором случае включается своп, flush (если данные менялись).

open() mmap() madvise() for (i = 0; i < 4096; i++) { /* touch page */ madvise(MADV_DONTNEED) } munmap() close()

где там 4х-кратное ?

> Ситуация: вы читаете по байту из произвольной страницы. 4096 чтений. В результате занята _одна_ анонимная пользовательская страница.

гыыыыыыыыыыыыыыы

попробуй-ка прочитать один байт через directIO, теоретик хренов.

>> Ситуация: вы читаете по байту из произвольной страницы. 4096 чтений. В результате занята _одна_ анонимная пользовательская страница.

>за такое использование read'а и расположение данных нужно руки отрывать. еще расскажи как оракл читает по одному байту .. ага ...

Суть от этого не меняется - будет читать по сектору или по любому другому маленькому блоку.

Слив защитан.

>> 1. fadvise, read, sync, fadvise для каждого чтения, итого в 4 раза увеличенные накладные расходы.

>fadvise делается один раз, при открытии файла. read делается точно такой же, даже тем же ->readpage() sync не нужен, или чтение через mmap грязнит страницы? directIO будет делать проход по pgtable, чтобы пользовательские страницы залочить в памяти

Файл на несколько сог гигабайт, он не помещается в page cache и в ram - почитайте сначала, о чем идет речь. У нас одна страница для чтения, pgtable содержит только ее.

> Более того, когда вы работаете с mmap, во время msync() вы не сможете ни читать данные (елси нужно делать дополнительный mmap(), а в нашем тесте это как раз нужно), ни изменять (запись в конец с увеличением размера).

докажешь или будешь песдеть?

я вот докажу:

sys_msync() up_read(&mm->mmap_sem); do_fsync(); filemap_fdatawrite(); filemap_fdatawait();

ну так кто тут будет мешать писать/читать "данные" ?

теоретик ...

>open() mmap() madvise() for (i = 0; i < 4096; i++) { /* touch page */ madvise(MADV_DONTNEED) } munmap() close()

>где там 4х-кратное ?

первый madvice() вычитает весь файл или сколько? Файл на сотни гагабайт, он в память не помещается. Все, вас дальше можно не читать.

Вы глупы.

sys_msync() -> down_read().

sys_mmap() -> down_write().

sys_madvise() -> down_write().

> Файл на несколько сог гигабайт, он не помещается в page cache и в ram - почитайте сначала, о чем идет речь. У нас одна страница для чтения, pgtable содержит только ее.

ну да, ну да.

for (i = 0; i < 4096; i++) { mmap() /* touch */ munmap(); }

не говоря уже про то, что: 1) ни один нормальный гражданин "несколько сог гигабайт" на 32bit давно не делает 2) весь файл можно разбить на 3GB куски и mmap/munmap делать только при переходе из одного куска в другой

PS. сколько уж тебе можно было сливов засчитать ..

> Вы глупы. > sys_msync() -> down_read(). > sys_mmap() -> down_write(). > sys_madvise() -> down_write().

гыыыыыыыыыыыыы

sys_msync(): down_write(&current->mm->mmap_sem);

generic_file_aio_write(): mutex_lock(&inode->i_mutex);

так и каким местом они пересекаются? :)

> первый madvice() вычитает весь файл или сколько? Файл на сотни гагабайт, он в память не помещается. Все, вас дальше можно не читать.

первый madvise() нужен чтобы read-ahead отключить. ты и не читал ни разу. ни меня, ни код. "смотрел по диагонали" msync() мешает write() .. ага.

>> Вы глупы. > sys_msync() -> down_read(). > sys_mmap() -> down_write(). > sys_madvise() -> down_write().

>гыыыыыыыыыыыыы

>sys_msync(): down_write(&current->mm->mmap_sem);

>generic_file_aio_write(): mutex_lock(&inode->i_mutex);

>так и каким местом они пересекаются? :)

Тяжелый случай... Подозреваю, что даже неизлечимый.

Вы смотрели, что я написал выше? Для случаев, когда требуется дополнительный mmap() или madvise(). Даже в вашем коде в цикле делается 2 инструкции вместо одной (во втором варианте, первый был вообще неработоспособен), причем обе - mmap() и madvise() повисают на том же самом mmap_sem, который взят для чтения msync()'ом.

> причем обе - mmap() и madvise() повисают на том же самом mmap_sem, который взят для чтения msync()'ом.

не нужно лжи:

up_read(&mm->mmap_sem); error = do_fsync(file, 0); fput(file); if (error || start >= end) goto out; down_read(&mm->mmap_sem);

bash-3.1$ head Makefile VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 20 EXTRAVERSION = NAME = Homicidal Dwarf Hamster

Показываю код:

asmlinkage long sys_madvise(unsigned long start, size_t len_in, int behavior)
{
	unsigned long end, tmp;
	struct vm_area_struct * vma, *prev;
	int unmapped_error = 0;
	int error = -EINVAL;
	size_t len;

	down_write(&current->mm->mmap_sem);

mmap:
...
	down_write(&mm->mmap_sem);
	error = do_mmap_pgoff(file, addr, len, prot, flags, pgoff);


asmlinkage long sys_msync(unsigned long start, size_t len, int flags)
{
 ....
	/*
	 * If the interval [start,end) covers some unmapped address ranges,
	 * just ignore them, but return -ENOMEM at the end.
	 */
	down_read(&mm->mmap_sem);
	vma = find_vma(mm, start);
	for (;;) {

По-моему, уже хватит.

Сам ->fsync() конечно без mmap_sem, но поиск vma (а это наиболее медленная операция, sync для одной страницы - несколкьо десятков мегабайт в секунду, если не было seek (а в тесте seek не делается между чтениями/записями), и даже быстрее, если диск поддерживает cache) - обязательно залочен. Более того, т.к. vma не удаляются, то со временем залоченный поиск будет занимать времени все больше и больше.

mmap в Linux к сожалению не самая высокопроизводительная часть - его главной проблемой является как раз mmap_sem.

> Сам ->fsync() конечно без mmap_sem, но поиск vma (а это наиболее медленная операция, sync для одной страницы - несколкьо десятков мегабайт в секунду, если не было seek (а в тесте seek не делается между чтениями/записями), и даже быстрее, если диск поддерживает cache) - обязательно залочен. Более того, т.к. vma не удаляются, то со временем залоченный поиск будет занимать времени все больше и больше.

ага. читать random'ом по байту - несколько мегабайт в секунду. разве что с SSD.

и проход по дереву с глубиной 1-3 в памяти оказывается медленнее синхронного IO.

и vma еще не удаляются ... тебе бы в церкву лучше ходить

> По-моему, уже хватит.

давно уже хватит. random access без seek'ов теперь делается. ах да, sys_lseek() имелся ввиду. бугага.

> Более того, т.к. vma не удаляются, то со временем залоченный поиск будет занимать времени все больше и больше.

дайте еще одну звезду герою! :)

Юный друк, вы все не уйметесь? :)

Вы же показали выше пример: mmap, msync, madvise - в msync'e не будет seek, в madvise не будет удаления vma. Для этого вам нужно делать mmap/fadvise/msync/munmap. А seek только при следующем доступе.

Похоже, что я за вас написал, как нужно работать с mmap, но даже в этом случае 4х-кратное (3х-кратное без msync) увеличение числа систмных вызовов по сравнению с directio.

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

В догонку - для максимального результата используйте directio в связке с async IO - для вашей задачи скорость будет еще выше.

> Похоже, что я за вас написал, как нужно работать с mmap, но даже в этом случае 4х-кратное (3х-кратное без msync) увеличение числа систмных вызовов по сравнению с directio.

цифры-то покажете или так и будете дальше песдеть, что IO стало быстрее vma lookup?

после этого говорить о чужом диагнозе совершернно неактуально.

> Похоже, что я за вас написал, как нужно работать с mmap, но даже в этом случае 4х-кратное (3х-кратное без msync) увеличение числа систмных вызовов по сравнению с directio.

msync() после чтения? уважаю!

> Тем, что вы снова не читали, что для вас написано выше, вы лишь подтвердили мой диагноз.

самое смешное, что настоящий недостаток mmap так не смог озвучить.

> В догонку - для максимального результата используйте directio в связке с async IO - для вашей задачи скорость будет еще выше.

максимальной кривости? безусловно. и в случае записи в hole сваливаться в buffered IO. обалденный механизм, прямо из 21 века!

мля, представил себе ребят в oracle (chris mason, etc), делающих direct IO для случайного чтения одиночных байт в очень больших файлах :)

>> Похоже, что я за вас написал, как нужно работать с mmap, но даже в этом случае 4х-кратное (3х-кратное без msync) увеличение числа систмных вызовов по сравнению с directio.

>msync() после чтения? уважаю!

Мы ввели msync() для случаев записи, что и было описано выше, без него у нас всего лишь 3хкратные накладные расходы...

А вы все продолжаете тупить.

>мля, представил себе ребят в oracle (chris mason, etc), делающих direct IO для случайного чтения одиночных байт в очень больших файлах :)

А так и делают - от 16-32 байт запрос через libaio. Я для вас открыл глаза?

>> В догонку - для максимального результата используйте directio в связке с async IO - для вашей задачи скорость будет еще выше.

>максимальной кривости? безусловно. и в случае записи в hole сваливаться в buffered IO. обалденный механизм, прямо из 21 века!

Вы понятия не имеете, о чем говорите. Async IO единственный способ получить максимальную производительность для случайного чтения/записи. libaio поддерживает только directio, здесь конечно не до конца доработали. Если вы чего-то не понимаете и не знаете, то это еще не означает, что это неправильно.

>А так и делают - от 16-32 байт запрос через libaio. Я для вас открыл глаза?

Стоит добавить, что из-за того, что в каждой транзакции объединяется до нескольких десятков тысяч таких запросов, IO планировщик выстраивает их наиболее оптимально.

Для тех, кто в танке, libaio создана в IBM, там тоже забыли проконсультироваться с анонимусом ЛОРа?

> А вы все продолжаете тупить.

куда уж мне до эксперта в области накладных расходов pagecache ;)

> А так и делают - от 16-32 байт запрос через libaio. Я для вас открыл глаза?

как только научите direct I/O работать с 16-32 байта - приходите.

> Для тех, кто в танке, libaio создана в IBM, там тоже забыли проконсультироваться с анонимусом ЛОРа?

угу, создана. только вот AIO нормального до сих пор нет. а так-то да, IBM :)

> Стоит добавить, что из-за того, что в каждой транзакции объединяется до нескольких десятков тысяч таких запросов, IO планировщик выстраивает их наиболее оптимально.

ауеть. IO планировщик, выстраивающий десятки тысяч однобайтных directIO.

> Мы ввели msync() для случаев записи, что и было описано выше, без него у нас всего лишь 3хкратные накладные расходы...

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

> что в каждой транзакции объединяется до нескольких десятков тысяч таких запросов, IO планировщик выстраивает их наиболее оптимально.

> Для тех, кто в танке, libaio создана в IBM, там тоже забыли проконсультироваться с анонимусом ЛОРа

Снимаю шляпу. Вы мастер путать следы, мутить воду и выдавать бузину в огороде за дядьку в Киеве.