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

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

Я все достаточно ясно описал, личная неприязнь не должна мешать видеть факты.

Если же вы придираетесь к libaio, так это подсказка разработчику, кто сделал первоначальный запрос.

> личная неприязнь

Для протокола - никакой личной неприязни. Мы даже не знакомы.

> Если же вы придираетесь к libaio, так это подсказка разработчику, кто сделал первоначальный запрос.

только вот место работы и квалификация разработчиков libaio не имела никакого отношения к страничному кэшу, поиску vma и синхронизации при исползовании mmap.

P.S. [mf]advise, через "s", не "c"

> Я все достаточно ясно описал, личная неприязнь не должна мешать видеть факты.

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

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

Вы идиот. Читать один или 16 или 32 байта весьма просто - в залоченную страницу будет скопировано ровно столько, сколько запрошено, хотя с диска прочтется блок.

Даже если читать 4к или 64к, или сколько вам угодно, для произвольного доступа в файле, заметно превышающем размер ram, directio дает заметный выигрыш. В случае использования aio - скорость становится близка к скорости линейного чтения (с ростом количества асинхронных запросов конечно же).

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

Я думаю, что вы уже давно поняли, в чем вы не правы, но продолжаете троллить, чтобы оставить последнее слово за собой.

Оставляйте :)

> Вы идиот. Читать один или 16 или 32 байта весьма просто - в залоченную страницу будет скопировано ровно столько, сколько запрошено, хотя с диска прочтется блок.

скопировано?! ну тут я пасс :)

directIO с копированием .. "а мужики-то не знали"

>только вот место работы и квалификация разработчиков libaio не имела никакого отношения к страничному кэшу, поиску vma и синхронизации при исползовании mmap.

Конечно не имела, я и не утверждал подобного. Проверьте несколькими сообщениями выше - я указал, что для бОльшей производительности можно использовать libaio, на что глупый анонимус вскричал, что это глупость.

Вы тоже ищите к чему бы придраться и склеиваете вещи, которые изначально не имели ничего общего? Разочарован.

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

это вы так и не поняли. что по-сути pagecache ничем от анонимных страниц не отличается. api только разное немного.

> Разочарован

понимаю. найти поклонников своего гения не получилось :)

> глупый анонимус вскричал, что это глупость

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

:)

>> Вы идиот. Читать один или 16 или 32 байта весьма просто - в залоченную страницу будет скопировано ровно столько, сколько запрошено, хотя с диска прочтется блок.

>скопировано?! ну тут я пасс :)

>directIO с копированием .. "а мужики-то не знали"

Детский сад. Вы снова несете чушь, начните думать мозгом, а не тем, что у вас в голове.


__blockdev_direct_IO() -> direct_io_worker() -> do_direct_IO() -> dio_get_page() /в памяти одна страница пользователя, куда будет считан один блок/

userspace:
read(buf, 1) - будет считан один блок
memcpy(&user_data[user_index], buf, 1)
user_index++;

Это делается, т.к. в задаче читается один байт с каждой страницы в случайном порядке. Если байт больше, читается столько, сколько нужно.

>это вы так и не поняли. что по-сути pagecache ничем от анонимных страниц не отличается. api только разное немного.

Вы другой анонимус или тот же? похоже, что другой :)

Я знаю, что такое анонимные страницы. Но дело в том, что в случае использования page cache, для каждого блока выделена своя страница, а без его использования данные кладутся в _одну_ и туже анонимную страницу.

read(buf, size); - данные лежат и в buf, и в page cache, в случае случайного доступа к огромному файлу, в page cache не будет повторного доступа, поэтому страницы будут просто занимать место, вызывая своп приложения в коце концов и flush их на диск (или просто выбрасывание, если нет записи).

Если дабвим сюда fadvise, то память не используется, но добавляется куча лишних вызовов для каждой операции чтения. Даже если отключить readahead, то все равно нужен дополнительный вызов для сбрасывания страницы.

> Если дабвим сюда fadvise, то память не используется, но добавляется куча лишних вызовов для каждой операции чтения. Даже если отключить readahead, то все равно нужен дополнительный вызов для сбрасывания страницы.

Вот и получаем, что в "куча лишних вызовов" - это 1 вызов. Если учесть, что системные вызовы в Linux дешевы, и в данном конкретном случае в системном вызове не происходит никиакой работы, то, на фоне только что случившегося В/В накладные расходы просто потеряются.

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

А теперь вы снова вырвали фразу из контекста :)

Анонимус уже согласился с тем, что 4х(3х без msync) кратное увеличения системных вызовов - это результат его дизайна? Или огромные накладные расходы на page cache, когда он не используется?

Анонимус в своем коде не вызвал munmap(), поэтому его vma не удалились. А следовательно для каждого нового mmap их дерево будет расти. Анонимус знает, как выглядит производительность get_user_pages() с ростом размера? Примерно как функция квадратного корня, только с выходом на горизонтальную прямую. Анонимус знает, из-за чего это? Это именно из-за поиска vma.

Анонимус не возразил насчет того, что поиск vma дороже синхронного IO, анонимус возразил на то, что msync() не дает выполняться madvise() и mmap(), а он _действительно_ не дает им выполняться, когда идет поиск vma, но дает это сделать, когда идет flush(). В описываемом примере между получением данных и msync() не было дополнительных чтений, а следовательно seek не станет выполнятся и flush пройдет очень быстро, но анонимус понял, что ошибся, и поэтому начал кричать глупости о том, что "случайный доступ без seek" и т.п. глупости. Продолжать то, что "забыл" анонимус?

>Вот и получаем, что в "куча лишних вызовов" - это 1 вызов. Если учесть, что системные вызовы в Linux дешевы, и в данном конкретном случае в системном вызове не происходит никиакой работы, то, на фоне только что случившегося В/В накладные расходы просто потеряются.

Вы дождались этого вывода от меня, не показав сами. Ладно, с вами хоть можно адекватно беседовать :)

Один дополнительный системный вызов - это сотни наносекунд, в случае записи в произвольный блок - это два дополнительных вызова. При этом вы _ничего_ не получаете в замен. Абсолютно.

Без AIO _наверное_ результат будет незначительно хуже, но при асинхронном вызова это уже очень накладно.

Также стоит отметить, что пока не существует асинхронного ввода/вывода для обычных операций, только directio.

> Вы дождались этого вывода от меня, не показав сами.

Учитывая, насколько "охотно" вы соглашаетесь с чужим мнением, я просто не озвучивал этот вывод.

> Без AIO _наверное_ результат будет незначительно хуже

Тоже так думаю. А тонкую настройку В/В нужно осуществлять уже для очень конкретных алгоритмов и use cases.

Пойнт в том, что страничный кэш вполне поддается управлению и является гораздо меньшим злом, чем считают фанаты direct I/O.

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

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

>> Без AIO _наверное_ результат будет незначительно хуже

>Тоже так думаю. А тонкую настройку В/В нужно осуществлять уже для очень конкретных алгоритмов и use cases.

При этом вы снова опустили то, что в некоторых задачах использование page cache не дает ничего, кроме накладных расходов (может быть маленьких, а может быть нет, но тем не менее всегда _дополнительных_).

>Пойнт в том, что страничный кэш вполне поддается управлению и является гораздо меньшим злом, чем считают фанаты direct I/O.

При этом все же directio (и раньше raw device) используются _намного_ чаще, чем fadvise().

> вы снова опустили то, что в некоторых задачах использование page cache не дает ничего, кроме накладных расходов (может быть маленьких, а может быть нет, но тем не менее всегда _дополнительных_).

Я не спорю с этим. Весь вопрос только в величине накладных расходов. Например, если это 1%, то стоит ли это оверхеда на поддержку 2-х механизмов чтения в коде ядра? Не проще ли добавить в fadvise флаг "не кэшировать ващеблин"...

> directio (и раньше raw device) используются _намного_ чаще, чем fadvise().

так они и старше намного

>> вы снова опустили то, что в некоторых задачах использование page cache не дает ничего, кроме накладных расходов (может быть маленьких, а может быть нет, но тем не менее всегда _дополнительных_).

>Я не спорю с этим. Весь вопрос только в величине накладных расходов. Например, если это 1%, то стоит ли это оверхеда на поддержку 2-х механизмов чтения в коде ядра? Не проще ли добавить в fadvise флаг "не кэшировать ващеблин"...

С directio работает aio, пока не будет альтернативы для buffered IO, directio вне конкуренции для подобного рода задач.

В связке с aio, directio дает близкую к последовательному скорость чтения (блоки по 4к, ext3 - cвыше 30мб/с) для _случайного_ доступа в файле. Без aio точных данных у меня нет.

>> directio (и раньше raw device) используются _намного_ чаще, чем fadvise().

>так они и старше намного

posix придумал этот вызов в 2001 году - вполне вероятно, чтобы заполнить нишу системных вызовов. В Linux реализован в 2003 - значит не нужен он был никому, раз так долго тянули... Да и сейчас не используется.

> С directio работает aio, пока не будет альтернативы для buffered IO, directio вне конкуренции

работы ведутся...

> posix придумал этот вызов в 2001 году - вполне вероятно, чтобы заполнить нишу системных вызовов. В Linux реализован в 2003 - значит не нужен он был никому

точнее, те, кому он был нужен, уже пользовались raw devices, реализованными еще для 2.2

> Анонимус в своем коде не вызвал munmap(), поэтому его vma не удалились.

будем цитировать? Ctrl-F пользовать умеешь?

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

> Это именно из-за поиска vma. да-да, среди нескольких десятков vma, жутко дорого, ага. дороже IO.

точно. это я сравнивал сравнивал взятие семафора и поиск в дереве с операцией IO:

"сам ->fsync() конечно без mmap_sem, но поиск vma (а это наиболее медленная операция, sync для одной страницы - несколкьо десятков мегабайт в секунду"

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

при чем тут msync(), спрашивается?

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

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

> При этом все же directio (и раньше raw device) используются _намного_ чаще, чем fadvise()

криворукие плодят гуано, с чем их и поздравляем. даже не представляя, что основное назначение directIO - сократить издержки на memcpy, а вовсе не на pagecache. сам rtc это так и не смог осилить. теоретик. выше 30MB/s ничего не видел.

> что msync() не дает выполняться madvise() и mmap(), а он _действительно_ не дает им выполняться, когда идет поиск vma, но дает это сделать, когда идет flush().

ничего, что все write блокируются на i_mutex, а read на i_truncate_mutex? теоретик :)

>ничего, что все write блокируются на i_mutex, а read на i_truncate_mutex? теоретик :)

Вы говорите правильные вещи, только абсолютно не по теме - речь шла о блокировании madvise/mmap на mmap_sem, взятом msync(). Идите читайте, что написано выше.

>будем цитировать? Ctrl-F пользовать умеешь?

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

Наконец-то вы начали говорить по теме, а не пустыми фразами.

Я ошибся, т.к. munmap() перепутал с madvise() в этом случае. munmap() вызывает tlb flush, что еще более накладная операция, поэтому я думал вы ее не использовали.

Так что помимо дополнительных системных вызовов вы еще добавили tlb flush после каждого чтения/записи - отличная масштабируемая архитектура.

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

>при чем тут msync(), спрашивается?

msync() ввели для случая записи.

> Вы говорите правильные вещи, только абсолютно не по теме - речь шла о блокировании madvise/mmap на mmap_sem, взятом msync(). Идите читайте, что написано выше.

это просто ты не понимаешь написанного. что твои directIO так же блокируются на семафорах, снижая concurrency, что и mmap. msync(), кстати, после read'а не нужен, да? :)))

кстати ... для тех, кто давно в танке:

open() add = mmap() madvise(MADV_RANDOM) for (i = 0; i < 4096; i++) { remap_file_pages(addr, [new offset]) /* touch page */ madvise(MADV_DONTNEED) }

4х-кратный overhead :)

использование directIO во внутренний буфер из которого потом делается копирование :)

>open() add = mmap() madvise(MADV_RANDOM) for (i = 0; i < 4096; i++) { remap_file_pages(addr, [new offset]) /* touch page */ madvise(MADV_DONTNEED) }

>4х-кратный overhead :)

По системным вызовам двухкратный - 2 вызова и touch вместо одного в цикле.

Далее - если в состоянии замапить весь файл, зачем remap_file_range()? Если мапите весь файл, то попадаете в rlimit'ы для адресного пространства и максимального количества используемой памяти.

Хм, только сейчас обратил внимание, что madvise для каждого чтения тоже вызывает tlb flush - вы все еще хотите это использовать для случайного доступа к файлу?

> По системным вызовам двухкратный - 2 вызова и touch вместо одного в цикле.

touch - это использование данных

> Далее - если в состоянии замапить весь файл, зачем remap_file_range()? Если мапите весь файл, то попадаете в rlimit'ы для адресного пространства и максимального количества используемой памяти.

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

> Хм, только сейчас обратил внимание, что madvise для каждого чтения тоже вызывает tlb flush - вы все еще хотите это использовать для случайного доступа к файлу?

да. это адекватная цена для нормального универсального механизма.

не говоря уже про то, что сама постановка задачи "случайные однобайтовые чтения в огромном файле" дебильная изначально. потери на дисковых seek'ах будут на три порядка дороже любого tlb flush.

тем более, что full tlb flush не нужен, нужно скидывать только одну станицу из него. а корявостям direct IO не поможет ничто.

PS. когда уже поймешь чего mmap() не может нормально сделать?

>> По системным вызовам двухкратный - 2 вызова и touch вместо одного в цикле.

>touch - это использование данных

Это если их можно использовать прямо из файла, а если нужно составить структуру из разлдичных кусков? Придется копировать.

>> Далее - если в состоянии замапить весь файл, зачем remap_file_range()? Если мапите весь файл, то попадаете в rlimit'ы для адресного пространства и максимального количества используемой памяти.

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

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

>> Хм, только сейчас обратил внимание, что madvise для каждого чтения тоже вызывает tlb flush - вы все еще хотите это использовать для случайного доступа к файлу?

>да. это адекватная цена для нормального универсального механизма.

>не говоря уже про то, что сама постановка задачи "случайные однобайтовые чтения в огромном файле" дебильная изначально. потери на дисковых seek'ах будут на три порядка дороже любого tlb flush.

Любые случайные чтения, суть не меняется, главное, что файл не помещается в ram и page cache.

Чтение с tlb miss из памяти примерно в 200 раз медленнее. 13 циклов для ddr для обычного чтения и более 2200 при tlb miss.

>PS. когда уже поймешь чего mmap() не может нормально сделать?

Не понимаю вопроса. mmap не может в этой задаче? Или вообще? Или может, но плохо?

Этот сайт у меня открылся весьма поздно.

Самое интересное, что весь ЛОР дружно проигнорировал, что автор тестов ясно пишет, что с увеличением версии ядра производительность рейзер4 падает. Это полностью совпадает с моим опытом.

И автор теста делает утверждение, что разработчики ядра просто специально пишут код ядра таким образом, что бы рейзер4 работал медленее.

Я лично не уверен, что это возможная ситуация, но факт падения скорости рейзер4 с увеличением версии ядра трудно как либо объяснить.

уважаемый rtc, что вы могли бы сказать по поводу сравнения потокового вывода реализованного двумя способами: AIO и в IO треде? машина может быть и одно- и двух-ядерной, задача мб и IO- и cpu-bound (пока сложно сказать как много займёт обработка потока данных читаемого с сетевого интерфейса из нескольких источников). Сравнение я всё равно проведу, но интересно ваше мнение.

> Для тех, кто считает, что компрессия - это хорошо:

> Gzip - 3 files (zeros only, raw DV data from video camera, x86_64 kernel rpm file), 10 MB of data (10*1024*1024), done on tmpfs so no real disk speed factor. The CPU is AMD64 with 1 MB cache per core, 2600 MHz clock (clock scaling disabled). That's my typical usage pattern (well, not counting these zeros).

Ужыс - вы такиже удивлены что архивы не сжимаются второй раз? Для вас это открытие? (я про video camera и kernel rpm file)/ Кроме того кто сказал что на файлухе пользуюься gzip-ом? Там слегка другие алгоритмы.

Кстати, автор статьи автор же патчей рейзер4 для последнего ядра линуха. Он видоизменил код старых патчей, что бы они работали на новом ядре.

>А за что его посадили?

Жену убил. Она сказала, что raiserfs - sux.