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

Ответ 1

Microsoft, похоже, исправила эту проблему с помощью Windows 10 Fall Creators Update и Windows 10 Pro для рабочей станции.

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

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

Ответ 2

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

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

#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, чтобы найти самую дорогую часть - будь моим гостем.