Ядро, копирующее страницы CoW после завершения дочернего процесса - PullRequest
5 голосов
/ 16 мая 2019

В Linux всякий раз, когда процесс разветвляется, отображения памяти родительского процесса клонируются в дочерний процесс. В действительности, по соображениям производительности, для страниц установлено значение copy-on-write - изначально они являются общими и, в случае, если один из двух процессов записывает один из них, они затем будут клонировано (MAP_PRIVATE).

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

Я сделал простой тест, в котором у меня есть два компонента:

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

При некоторых обстоятельствах (машина / архитектура / размещение в памяти / количество потоков / ...) я могу завершить копирование намного раньше, чем потоки записывают в массив.

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

В моем понимании, если анонимная страница, помеченная как copy-on-write , отображается одним процессом, она не должна копироваться и вместо этого должна использоваться напрямую.

Как я могу быть уверен, что это действительно время, затрачиваемое на копирование памяти?

Если я прав, как мне избежать этих издержек?


Суть теста ниже, в modern C ++.

Определите WITH_FORK, чтобы включить снимок; оставьте неопределенным, чтобы отключить дочерний процесс.

#include <unistd.h>
#include <sys/mman.h>
#include <sys/types.h>
#include <sys/wait.h>

#include <numaif.h>
#include <numa.h>

#include <algorithm>
#include <cassert>
#include <condition_variable>
#include <mutex>
#include <iomanip>
#include <iostream>
#include <cmath>
#include <numeric>
#include <thread>
#include <vector>

#define ARRAY_SIZE 1073741824 // 1GB
#define NUM_WORKERS 28
#define NUM_CHECKPOINTERS 4
#define BATCH_SIZE 2097152 // 2MB

using inttype = uint64_t;
using timepoint = std::chrono::time_point<std::chrono::high_resolution_clock>;

constexpr uint64_t NUM_ELEMS() {
  return ARRAY_SIZE / sizeof(inttype);
}

int main() {

  // allocate array
  std::array<inttype, NUM_ELEMS()> *arrayptr = new std::array<inttype, NUM_ELEMS()>();
  std::array<inttype, NUM_ELEMS()> & array = *arrayptr;

  // allocate checkpoint space
  std::array<inttype, NUM_ELEMS()> *cpptr = new std::array<inttype, NUM_ELEMS()>();
  std::array<inttype, NUM_ELEMS()> & cp = *cpptr;

  // initialize array
  std::fill(array.begin(), array.end(), 123);

#ifdef WITH_FORK
  // spawn checkpointer threads
  int pid = fork();
  if (pid == -1) {
    perror("fork");
    exit(-1);
  }

  // child process -- do checkpoint
  if (pid == 0) {
    std::array<std::thread, NUM_CHECKPOINTERS> cpthreads;
    for (size_t tid = 0; tid < NUM_CHECKPOINTERS; tid++) {
      cpthreads[tid] = std::thread([&, tid] {
        // copy array
        const size_t numBatches = ARRAY_SIZE / BATCH_SIZE;
        for (size_t i = tid; i < numBatches; i += NUM_CHECKPOINTERS) {
          void *src = reinterpret_cast<void*>(
            reinterpret_cast<intptr_t>(array.data()) + i * BATCH_SIZE);
          void *dst = reinterpret_cast<void*>(
            reinterpret_cast<intptr_t>(cp.data()) + i * BATCH_SIZE);
          memcpy(dst, src, BATCH_SIZE);
          munmap(src, BATCH_SIZE);
        }
      });
    }
    for (std::thread& thread : cpthreads) {
      thread.join();
    }
    printf("CP finished successfully! Child exiting.\n");
    exit(0);
  }
#endif  // #ifdef WITH_FORK

  // spawn worker threads
  std::array<std::thread, NUM_WORKERS> threads;
  for (size_t tid = 0; tid < NUM_WORKERS; tid++) {
    threads[tid] = std::thread([&, tid] {
      // write to array
      std::array<inttype, NUM_ELEMS()>::iterator it;
      for (it = array.begin() + tid; it < array.end(); it += NUM_WORKERS) {
        *it = tid;
      }
    });
  }

  timepoint tStart = std::chrono::high_resolution_clock::now();

#ifdef WITH_FORK
  // allow reaping child process while workers work
  std::thread childWaitThread = std::thread([&] {
    if (waitpid(pid, nullptr, 0)) {
      perror("waitpid");
    }
    timepoint tChild = std::chrono::high_resolution_clock::now();
    std::chrono::duration<double> durationChild = tChild - tStart;
    printf("reunited with child after (s): %lf\n", durationChild.count());
  });
#endif

  // wait for workers to finish
  for (std::thread& thread : threads) {
    thread.join();
  }
  timepoint tEnd = std::chrono::high_resolution_clock::now();
  std::chrono::duration<double> duration = tEnd - tStart;
  printf("duration (s): %lf\n", duration.count());

#ifdef WITH_FORK
  childWaitThread.join();
#endif
}

1 Ответ

3 голосов
/ 17 мая 2019

Размер массива составляет 1 ГБ, что составляет около 250 КБ страниц, где каждая страница имеет размер 4 КБ.Для этой программы можно легко оценить количество сбоев страниц, возникающих из-за записи на страницы CoW.Его также можно измерить с помощью инструмента Linux perf.Оператор new инициализирует массив нулем.Поэтому следующая строка кода:

std::array<inttype, NUM_ELEMS()> *arrayptr = new std::array<inttype, NUM_ELEMS()>();

вызовет около 250K сбоев страницы.Точно так же следующая строка кода:

std::array<inttype, NUM_ELEMS()> *cpptr = new std::array<inttype, NUM_ELEMS()>();

вызовет еще 250 страниц сбоя.Все эти ошибки страницы второстепенные , т. Е. Они могут быть обработаны без доступа к дисководу.Выделение двух массивов по 1 ГБ не вызовет серьезных сбоев в системе с гораздо большей физической памятью.

На этом этапе уже произошло около 500K сбоев страниц (будут другие сбои страниц, вызванные другими обращениями к памяти изпрограмма, конечно, но ими можно пренебречь).Выполнение std::fill не вызовет каких-либо незначительных сбоев, но виртуальные страницы массивов уже были сопоставлены с выделенными физическими страницами.

Затем выполнение программы переходит к разветвлению дочернего процесса и созданию рабочегопотоки родительского процесса.Создание дочернего процесса само по себе достаточно для создания моментального снимка массива, поэтому на самом деле нет необходимости что-либо делать в дочернем процессе.Фактически, когда дочерний процесс разветвляется, виртуальные страницы обоих массивов помечаются как копируемые при записи.Дочерний процесс читает из arrayptr и записывает в cpptr, что приводит к дополнительным 250K незначительным сбоям.Родительский процесс также записывает в arrayptr, что также приводит к дополнительным 250K незначительным сбоям.Таким образом, создание копии в дочернем процессе и отключение страниц не повышает производительность.Напротив, количество сбоев страниц удваивается, а производительность значительно снижается.

Вы можете измерить количество мелких и серьезных сбоев, используя следующую команду:

perf stat -r 3 -e minor-faults,major-faults ./binary

Это будет,по умолчанию подсчитывать второстепенные и мелкие неисправности для всего дерева процессов.Опция -r 3 указывает perf повторить эксперимент три раза и сообщить среднее и стандартное отклонение.

Я также заметил, что общее количество потоков равно 28 + 4. Оптимальное количество потоков составляет примерноравно общему количеству сетевых логических ядер в вашей системе.Если количество потоков намного больше или намного меньше этого, производительность будет ухудшаться из-за накладных расходов, связанных с созданием слишком большого количества потоков и переключением между ними.

Другая потенциальная проблема может существовать в следующем цикле:

for (it = array.begin() + tid; it < array.end(); it += NUM_WORKERS) {
  *it = tid;
}

Разные потоки могут пытаться записывать несколько раз в одну и ту же строку кэша в одно и то же время, что приводит к ложному разделению .Это может не быть существенной проблемой в зависимости от размера строки кэша вашего процессора, количества потоков и от того, все ли ядра работают на одной частоте, поэтому трудно сказать без измерения.Лучшая форма петли будет иметь элементы каждого потока, чтобы быть непрерывными в массиве.

...