Низкая производительность Windows 10 по сравнению с Windows 7 (обработка ошибок страниц не масштабируется, серьезный конфликт блокировок при отсутствии потоков > 16)

Похоже, Microsoft исправила эту проблему в Windows 10 Fall Creators Update и Windows 10 Pro for Workstation.

Вот обновленный график.

Win 10 FCU и WKS имеют меньшие накладные расходы, чем Win 7. Взамен VirtualLock, похоже, имеет более высокие накладные расходы.

К сожалению, это не ответ, а просто дополнительная информация.

Небольшой эксперимент с другой стратегией распределения:

#include <Windows.h>

#include <thread>
#include <condition_variable>
#include <mutex>
#include <queue>
#include <atomic>
#include <iostream>
#include <chrono>

class AllocTest
{
public:
    virtual void* Alloc(size_t size) = 0;
    virtual void Free(void* allocation) = 0;
};

class BasicAlloc : public AllocTest
{
public:
    void* Alloc(size_t size) override {
        return VirtualAlloc(NULL, size, MEM_RESERVE | MEM_COMMIT, PAGE_READWRITE);
    }
    void Free(void* allocation) override {
        VirtualFree(allocation, NULL, MEM_RELEASE);
    }
};

class ThreadAlloc : public AllocTest
{
public:
    ThreadAlloc() {
        t = std::thread([this]() {
            std::unique_lock<std::mutex> qlock(this->qm);
            do {
                this->qcv.wait(qlock, [this]() {
                    return shutdown || !q.empty();
                });
                {
                    std::unique_lock<std::mutex> rlock(this->rm);
                    while (!q.empty())
                    {
                        q.front()();
                        q.pop();
                    }
                }
                rcv.notify_all();
            } while (!shutdown);
        });
    }
    ~ThreadAlloc() {
        {
            std::unique_lock<std::mutex> lock1(this->rm);
            std::unique_lock<std::mutex> lock2(this->qm);
            shutdown = true;
        }
        qcv.notify_all();
        rcv.notify_all();
        t.join();
    }
    void* Alloc(size_t size) override {
        void* target = nullptr;
        {
            std::unique_lock<std::mutex> lock(this->qm);
            q.emplace([this, &target, size]() {
                target = VirtualAlloc(NULL, size, MEM_RESERVE | MEM_COMMIT, PAGE_READWRITE);
                VirtualLock(target, size);
                VirtualUnlock(target, size);
            });
        }
        qcv.notify_one();
        {
            std::unique_lock<std::mutex> lock(this->rm);
            rcv.wait(lock, [&target]() {
                return target != nullptr;
            });
        }
        return target;
    }
    void Free(void* allocation) override {
        {
            std::unique_lock<std::mutex> lock(this->qm);
            q.emplace([allocation]() {
                VirtualFree(allocation, NULL, MEM_RELEASE);
            });
        }
        qcv.notify_one();
    }
private:
    std::queue<std::function<void()>> q;
    std::condition_variable qcv;
    std::condition_variable rcv;
    std::mutex qm;
    std::mutex rm;
    std::thread t;
    std::atomic_bool shutdown = false;
};

int main()
{
    SetProcessWorkingSetSize(GetCurrentProcess(), size_t(4) * 1024 * 1024 * 1024, size_t(16) * 1024 * 1024 * 1024);

    BasicAlloc alloc1;
    ThreadAlloc alloc2;

    AllocTest *allocator = &alloc2;
    const size_t buffer_size =1*1024*1024;
    const size_t buffer_count = 10*1024;
    const unsigned int thread_count = 32;

    std::vector<void*> buffers;
    buffers.resize(buffer_count);
    std::vector<std::thread> threads;
    threads.resize(thread_count);
    void* reference = allocator->Alloc(buffer_size);

    std::memset(reference, 0xaa, buffer_size);

    auto func = [&buffers, allocator, buffer_size, buffer_count, reference, thread_count](int thread_id) {
        for (int i = thread_id; i < buffer_count; i+= thread_count) {
            buffers[i] = allocator->Alloc(buffer_size);
            std::memcpy(buffers[i], reference, buffer_size);
            allocator->Free(buffers[i]);
        }
    };

    for (int i = 0; i < 10; i++)
    {
        std::chrono::high_resolution_clock::time_point t1 = std::chrono::high_resolution_clock::now();
        for (int t = 0; t < thread_count; t++) {
            threads[t] = std::thread(func, t);
        }
        for (int t = 0; t < thread_count; t++) {
            threads[t].join();
        }
        std::chrono::high_resolution_clock::time_point t2 = std::chrono::high_resolution_clock::now();

        auto duration = std::chrono::duration_cast<std::chrono::microseconds>(t2 - t1).count();
        std::cout << duration << std::endl;
    }


    DebugBreak();
    return 0;
}

При всех вменяемых условиях BasicAlloc быстрее, как и должно быть. Фактически, на четырехъядерном процессоре (без HT) нет созвездия, в котором ThreadAlloc мог бы превзойти его. ThreadAlloc постоянно примерно на 30% медленнее. (Что на самом деле на удивление мало, и это справедливо даже для крошечных выделений в 1 КБ!)

Однако, если ЦП имеет около 8-12 виртуальных ядер, то в конечном итоге он достигает точки, когда BasicAlloc фактически масштабируется отрицательно, в то время как ThreadAlloc просто «останавливается» на базовых накладных расходах на программные сбои.

Если вы профилируете две разные стратегии распределения, вы увидите, что при малом количестве потоков KiPageFault смещается с memcpy на BasicAlloc на VirtualLock на ThreadAlloc.

Для большего числа потоков и ядер в конечном итоге ExpWaitForSpinLockExclusiveAndAcquire начинает подниматься от практически нулевой нагрузки до 50% с BasicAlloc, в то время как ThreadAlloc поддерживает только постоянные накладные расходы от самого KiPageFault.

Ну и стойло с ThreadAlloc тоже довольно нехорошо. Независимо от того, сколько ядер или узлов в системе NUMA у вас есть, в настоящее время вы жестко ограничены примерно 5-8 ГБ/с в новых выделениях для всех процессов в системе, ограничиваясь исключительно производительностью одного потока. Все, чего достигает выделенный поток управления памятью, — это не тратить циклы ЦП на спорный критический раздел.

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

Спин-блокировка также уже присутствовала в Windows 7 и более ранних реализациях KiPageFault. Так что же изменилось?

Простой ответ: KiPageFault сам стал намного медленнее. Понятия не имею, что именно вызвало его замедление, но спин-блокировка просто никогда не становилась очевидным ограничением, потому что раньше 100% конкуренция была невозможна.

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