与Windows 7相比，Windows 10性能较差（页面error handling不可伸缩，当线程数大于16时严重的锁争用）

微软似乎已经解决了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更快，就像它应该那样。 事实上，在一个四核CPU（没有HT）上，没有任何一个ThreadAlloc可以超越它的星座。 ThreadAlloc速度一直在30％左右。 （实际上这实际上很少，而且即使对于1kB的微小分配也是如此！）

但是，如果CPU有8-12个虚拟核心，那么它最终到达BasicAlloc实际缩放的点，而ThreadAlloc只是在软故障的基线开销“停顿”。

如果分析两种不同的分配策略，可以看到对于低线程数， KiPageFault从BasicAlloc上的memcpy转换为BasicAlloc上的VirtualLock 。

对于更高的线程和内核数量，最终ExpWaitForSpinLockExclusiveAndAcquire开始从几乎零加载到BasicAlloc高达50％，而ThreadAlloc只维护KiPageFault本身的常量开销。

那么，与ThreadAlloc的摊位也非常糟糕。 无论您的NUMA系统中有多少个核心或节点，在系统中的所有进程中，您目前都被限制在大约5-8GB / s的新分配，完全受单线程性能限制。 所有的专用内存管理线程都达到了，不会浪费在竞争关键部分的CPU周期。

你可能会预料到，微软在不同核心上分配页面的策略是无锁的，但显然这并不是那么简单。

自旋锁也已经出现在Windows 7和早期的KiPageFault实现中。 那么改变了什么？

简单的答案： KiPageFault本身变得更慢。 不知道究竟是什么造成了减速，但自旋锁从来没有成为一个明显的限制，因为100％的争夺以前是不可能的。

如果有人希望拆卸KiPageFault以找到最昂贵的部分 – 做我的客人。