Page fault

[idle0]

Исходный пойнт был - при копировании файлов ВСЕГДА используется свап независимо от размеров свободной памяти, и как следствие количество пейдж фолтов не может указывать на недостаток физической памяти.
Мой пойнт - все до лампочки, независимо от операции, когда все можно поместить в физическую память, своп не будет использован. То есть количество пейдж фолтов прймао говорит о недостатке физической памяти.
А про операционки, копирующие через своп - я вооще молчу...

Вы не понимаете Доступ к файлам и копирование не идет через system swap. Просто на время открытия файла и операций с ниим он становится таким маленьким swap-ом, который используется только для доступа к этому файлу. От колличества памяти в системе это не зависит - понимаете? Это про Solaris, в Linux скорее всего тоже так, но я не уверен на 100%

[tengiz]

Просто на время открытия файла и операций с ниим он становится таким маленьким swap-ом, который используется только для доступа к этому файлу. От колличества памяти в системе это не зависит - понимаете? Это про Solaris, в Linux скорее всего тоже так, но я не уверен на 100%

Это верно только для приложений, которые пользуются memory mapped files для ввода/вывода (и, возможно, для всех исполняемых файлов - я не знаю этой детали про Solaris). Что, вообще говоря, эффективно и разумно только для определённых случаев. Если бы на Solaris это был единственный способ IO, то индустрия баз данных, скажем, не хотела бы иметь ничего общего с Sun. Потому что схемы кеширования, обеспечиваемые стандартными менеджерами виртуальной памяти, не годятся для СУБД, где от операционной системы нужен асинхронный небуферизованный ввод/вывод. Следовательно, предположение о том, что активная подкачка не обязательно означает нехватку физической памяти верно только тогда, когда точно известно, что большая часть IO действительно делается через mmap. Для чего, соответственно, нужно быть уверенным в том, как конкретно сделаны конкретные приложения в основном работающие в системе.

[idle0]

Просто на время открытия файла и операций с ниим он становится таким маленьким swap-ом, который используется только для доступа к этому файлу. От колличества памяти в системе это не зависит - понимаете? Это про Solaris, в Linux скорее всего тоже так, но я не уверен на 100%

Это верно только для приложений, которые пользуются memory mapped files для ввода/вывода (и, возможно, для всех исполняемых файлов - я не знаю этой детали про Solaris). Что, вообще говоря, эффективно и разумно только для определённых случаев. Если бы на Solaris это был единственный способ IO, то индустрия баз данных, скажем, не хотела бы иметь ничего общего с Sun. Потому что схемы кеширования, обеспечиваемые стандартными менеджерами виртуальной памяти, не годятся для СУБД, где от операционной системы нужен асинхронный небуферизованный ввод/вывод. Следовательно, предположение о том, что активная подкачка не обязательно означает нехватку физической памяти верно только тогда, когда точно известно, что большая часть IO действительно делается через mmap. Для чего, соответственно, нужно быть уверенным в том, как конкретно сделаны конкретные приложения в основном работающие в системе.

А для этого есть forcedirectio:

Code: Select all

forcedirectio | noforcedirectio
                      If  forcedirectio  is  specified  and  sup-
                      ported  by  the  file  system, then for the
                      duration of the mount  forced  direct   I/O
                      will  be used. If the filesystem is mounted
                      using   forcedirectio,   then    data    is
                      transferred  directly  between user address
                      space and the disk. If  the  filesystem  is
                      mounted  using   noforcedirectio, then data
                      is buffered in kernel  address  space  when
                      data  is  transferred  between user address
                      space and the disk. forcedirectio is a per-
                      formance  option  that  benefits  only from
                      large  sequential   data   transfers.   The
                      default behavior is  noforcedirectio.

[A. Fig Lee]

Исходный пойнт был - при копировании файлов ВСЕГДА используется свап независимо от размеров свободной памяти, и как следствие количество пейдж фолтов не может указывать на недостаток физической памяти.
Мой пойнт - все до лампочки, независимо от операции, когда все можно поместить в физическую память, своп не будет использован. То есть количество пейдж фолтов прймао говорит о недостатке физической памяти.
А про операционки, копирующие через своп - я вооще молчу...

Вы не понимаете Доступ к файлам и копирование не идет через system swap. Просто на время открытия файла и операций с ниим он становится таким маленьким swap-ом, который используется только для доступа к этому файлу. От колличества памяти в системе это не зависит - понимаете? Это про Solaris, в Linux скорее всего тоже так, но я не уверен на 100%

Да, не понимаю. Что значит - "становится маленьким свапом"? Свап в системе один - грубо говоря - виртуальная память. Каким образом ето становится "маленьким свапом"? Файл физически перемещается или что?
В случае использования мемори маппед файл (для чего угодно) - Вы можете аллокировать большое количество виртуальной памяти, больше, чем есть свободной физической - в етом случае будет участвовать свап. Если памяти меньше чем физической - свап не используется.
Ну Вы меня заставили таки заглянуть в Solaris internals - ничего подтверждающего Вашу мысль я там не нашел.

[f_evgeny]

..и, возможно, для всех исполняемых файлов - я не знаю этой детали про Solaris...

Исполняемые файлы всегда загружаются постранично. Называется - страничная подкачка по требованию. "Все, что в действительности требуется, - это структура пользователя и таблицы страниц. Если они загружены, то процесс считается находящимся в памяти и может быть запущен планировщиком. Страницы с сегментами текста, данных и стека загружаются в память динамически, по мере обращения к ним. Если пользовательской структуры и таблицы страниц нет в памяти, то процесс не может быть запущен, пока своппер не загрузит их" - Танненбаум, 2- е издание. (Здесь под текстом - по видимому имеется в виду программный код)

[A. Fig Lee]

Code: Select all

forcedirectio | noforcedirectio
                      If  forcedirectio  is  specified  and  sup-
                      ported  by  the  file  system, then for the
                      duration of the mount  forced  direct   I/O
                      will  be used. If the filesystem is mounted
                      using   forcedirectio,   then    data    is
                      transferred  directly  between user address
                      space and the disk. If  the  filesystem  is
                      mounted  using   noforcedirectio, then data
                      is buffered in kernel  address  space  when
                      data  is  transferred  between user address
                      space and the disk. forcedirectio is a per-
                      formance  option  that  benefits  only from
                      large  sequential   data   transfers.   The
                      default behavior is  noforcedirectio.

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

Даже если не в физической, то там своя отдельная имплементация, которая не приводит к пейдж фолтам. ("Solaris Internals" page 22).

[f_evgeny]

Давайте не будем горячится и спокойно во всем разберемся. (C)
Лично я знаю следующие виды активности с обращением к диску, которые можно заподозрить в генерации Page faults:
1. Выгрузк/подгрузка страниц из адресного пространства процессов своппером. Сюда входят также и отображаемые в память файлы. Page Faults генерятся. (При обращении к адресу, который находится на странице, которая не загружена в физическую память)
2. Подгрузка страниц в дисковый кэш. Когда из открытого файла процесс пытается считать данные, которые находятся на странице, которой нет в дисковом кэше. Тут насчет Page Faults ничего сказать не могу, надо ковырятся в интернете. Что скажут знатоки?

[tengiz]

Подгрузка страниц в дисковый кэш. Когда из открытого файла процесс пытается считать данные, которые находятся на странице, которой нет в дисковом кэше. Тут насчет Page Faults ничего сказать не могу, надо ковырятся в интернете.

Как уже было написано выше - это зависит от того, что конкретно хотело приложение, работающее с этим файлом и как точно этот файл был открыт. Memory mapped file - не самое лучшее и не самое универсальное решение. В том числе и для реализации системного файлового кеша - особенно когда файлов слишком много и адресного пространства ядра просто на хватит на то, чтобы вместить туда все открытые файлы целиком. А иначе связываеться с mmap для организации файлового кеша смысла мало. Более того, функциональность менеджера витруальной памяти, страничного и дискового кеша настолько друг с другом тесно связаны, что memory mapped files скорее как раз реализована на основе VMM/file cache. Т.е. всё как раз просиходит наоборот.

В общем, на самом деле вопрос упирается в точное определение page fault на Solaris. Если любой кеш-промах в VMM/file cache является page fault, то тогда idle0 совершенно справедливо полагает, что их большое количество не говорит о недостатке физической памяти. С другой стороны, информативность такого счётчика производительности близка к нулю и непонятно зачем он вообще нужен.

[A. Fig Lee]

Ну вроде бы так:

13.4 File system I/O:
Two distinct methods perform file system I/o:
- read, write and related system calls
- memory mapped files.

.. a process calls mmap() to map file into its address space for memory mapped I/O and the kernel maps the file into kernel's address space for read and write.

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

Once the file mapping is created in the process's address space, file pages are read when a fault occurs in the address space.

Короче в етом случае вызывается драйвер seg_vn, который тоже вызывается от MMU через as_fault() - то есть пейдж фолт регестрируется до вызова seg_vn, получается мемори маппед файл не регистрируют пейдж фолтов. (Лень все печaтать.)

[idle0]

Для всех неверующих

Запустите на Solaris "cp /var/tmp/largefile1 /var/tmp/largefile2"
и в это же время "sar -p 1 1000" и "vmstat -p 1"

В "sar" смотрите на vflt/s, а в "vmstat" на fpi/fpo (file system page-ins,
file system page-outs)

[A. Fig Lee]

Для всех неверующих

Запустите на Solaris "cp /var/tmp/largefile1 /var/tmp/largefile2"
и в это же время "sar -p 1 1000" и "vmstat -p 1"

В "sar" смотрите на vflt/s, а в "vmstat" на fpi/fpo (file system page-ins,
file system page-outs)

А где гарантия что cp не пытается аллокировать память для буффера, чтобы щитать данные из файла, и ее не хватает? У кого сурс есть?
2. Почему именно большой файл? попытайтесь маленький скопировать.

[Dmitry67]

tengiz очень правильно написал и опередели меня... я хотел встрять с тем 'а как же read ahead'

Кроме того операция открытия такого файла очень дорогостоящая.

Тут вы конечно про юниксы говорите но утверждение что "если памяти хватает то page faults=0" в общем случае неверно даже без memory mapped files. В той же NT если у вас до X...рена памяти они идут сотнями... А все потому что она жмет working set процессов, будь она неладна.

Как будто люди специально старались сделать систему как можно менее realtime. Чтобы если не работал час на компьютере то чтобы он как бы 'просыпался' подольше.

[idle0]

Небольшое дополнение: при копировании в Solaris файлов через "cp" деиствительно происходит много page faults, т.к. при этом используются memory mapped files

Если копировать тот-же фаил при помощи "dd" - page faults нет...

[A. Fig Lee]

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

Если копировать тот-же фаил при помощи "дд" - паге фаултс нет...

Ага, посмотрел. Точно, при использовании "cp" используются мемори маппед файлс и на Линухе и на ФриБСД, скорее всего почти везде.
2. Тут ситуация такая - приводит ли использование мемори маппед файлов к увеличению щетчика. Согласно многочисленным источникам, фолты всегда возникают при использовании мемори маппед файлов независимо от размера - как минимум при первом обращении. Значит, для чистоты експеримента достаточно копировать маленький файл в цикле - фолты все равно будут, если они регистрируются. Из Солярис Интерналс следует, что при обычной нехватке виртуальной памяти ММУ генерит пейдж фолт и ета пейдж загружается через драйвер. При мемори маппед файлс ММУ ничего не генерит - все вроде бы происходит черз прямой вызов етого драйвера, соответственно, надо полагать щетчик не увеличивается.
3. Почему при експериментах в етом случае растет количество фолтов?
Надо бы убедится что фолты происходят именно изза процесса копирования, а не как побочный продукт. Ведь если мы копируем большой файл, то часть физической мемори будет занята под мемори маппед и другим достанется меньше - они то и могут произвести пейдж фолты. С другой стороны, если мемори маппед файл таки регистрирует фалты - достаточно открыть штук 5 процессов по копированию маленьких файлов. Хотя, анивей, загружатся будет какоето количество пейджей независимо от сколь мал размер файла.
В общем, как бы убедится что именно мемори маппед файлы производят пейдж фолты, а не тот у кого они память отобрали.
4. Мои експерименты на Фре - пейдж фолт такой же как и раньше, несмотря на копирование.

[A. Fig Lee]

ну что - ни у кого больше мыслей нет?