Как устранить ошибки в огромных страницах в общей памяти с файловой поддержкой в ​​случае нескольких записывающих устройств - PullRequest
1 голос
/ 20 января 2020

У меня есть несколько писателей, которые будут mmap() несколько общих (т. Е. Указано MAP_SHARED) огромных страниц, подкрепленных файлом.

Обнуление (например, memset(ptr, 0, size)) этих огромных страниц может привести к сбою страниц заранее.

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

Вопросы:

  1. Есть ли способ заранее вызвать ошибки страниц, кроме обнуления / записи в страницы?
  2. Если нет, то каков общий способ сбивать страницы, не затрагивая читателей, которые читают, и писателей, которые пишут?

mmap(2) подразумевает, что mlock() может предустанавливать страницы:

MAP_LOCKED (since Linux 2.5.37)
              Mark the mapped region to be locked in the same way as
              mlock(2).  This implementation will try to populate (prefault)
              the whole range but the mmap() call doesn't fail with ENOMEM
              if this fails.  Therefore major faults might happen later on.
              So the semantic is not as strong as mlock(2).  One should use
              mmap() plus mlock(2) when major faults are not acceptable
              after the initialization of the mapping.  The MAP_LOCKED flag
              is ignored in older kernels.

Однако mlock(2) не указывает явно, что страницы будут сбойными при вызове mlock(). Мысль

1 Ответ

1 голос
/ 29 января 2020

Что касается mlock(2):

См. эти документы.

Ссылки на заблокированные страницы в этом процессе или в других процессах не приводят к странице ошибки, которые требуют операции ввода-вывода

Что касается вашего вопроса

  1. Есть ли способ заранее вызвать ошибки страниц, кроме обнуления / записи в страницы?

Да, есть способ «возможно». См. Флаг posix_madivse(3) POSIX_MADV_WILLNEED.

Также см. madvise(2), который намного более холодный, чем выше, с точки зрения возможностей, но не указано по любым стандартам.

...