You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Kernel non-paged pool "Mmdi" continuously increases memory usage until system runs out of memory and applications begin to crash.
How to Reproduce
Set up Windows 10 virtual machine under Linux/KVM. Install virtio-win guest tools and winfsp. Map host folders (large folders, containing 1M+ files) on the guest using virtio-fs and winfsp, as described here. Perform heavy disk i/o on the mapped folders on the guest (i.e. file contents indexing, rclone backup, etc).
Behaviors
Available memory on the guest decreases at a rate proportional to the amount of virtio-fs disk activity. Task Manager indicates the memory consumption is Non-paged pool. PoolMonX may be used to monitor kernel memory pool sizes, and it indicates the pool tag is "Mmdi".
Environment
-Windows 10 Pro 22H2 build 19045.3693
-WinFsp build 2.0.23075.0
-Virtio-win guest tools version 0.1.240
Additional supporting info
This screenshot shows the kernel memory pools immediately after rebooting the guest. Mmdi pool is allocated 4.6 MB.
This screenshot shows the kernel memory pools after several hours of disk i/o. Mmdi is now the largest allocated pool with 4,294 MB.
The following screenshot shows a graph of the Mmdi pool growth over 6 minutes, and the drivers associated with these memory allocations. The memory allocation trace was captured using xperf and WPA which are part of the Windows Performance Toolkit. The specific command used for the capture is as follows:
Since both viofs.sys and winfsp-x64.dll are both associated with this pool growth, I am not sure whether this suspected memory leak is caused by Virtio-fs or WinFsp, so we have filed bug reports in both github repos. The Virtio-fs bug report can be found here.
The text was updated successfully, but these errors were encountered:
I do not believe this memory leak is due to WinFsp:
The WinFsp kernel driver uses tags FspI and FspX and not Mmdi.
The winfsp-x64.dll is a user mode DLL and cannot allocate kernel memory directly. The DLL winfsp-x64.dll appears here simply because it provides the WinFsp API that is being used by the virtiofs file system.
Bug Report
Kernel non-paged pool "Mmdi" continuously increases memory usage until system runs out of memory and applications begin to crash.
How to Reproduce
Set up Windows 10 virtual machine under Linux/KVM. Install virtio-win guest tools and winfsp. Map host folders (large folders, containing 1M+ files) on the guest using virtio-fs and winfsp, as described here. Perform heavy disk i/o on the mapped folders on the guest (i.e. file contents indexing, rclone backup, etc).
Behaviors
Available memory on the guest decreases at a rate proportional to the amount of virtio-fs disk activity. Task Manager indicates the memory consumption is Non-paged pool. PoolMonX may be used to monitor kernel memory pool sizes, and it indicates the pool tag is "Mmdi".
Environment
-Windows 10 Pro 22H2 build 19045.3693
-WinFsp build 2.0.23075.0
-Virtio-win guest tools version 0.1.240
Additional supporting info
This screenshot shows the kernel memory pools immediately after rebooting the guest. Mmdi pool is allocated 4.6 MB.
This screenshot shows the kernel memory pools after several hours of disk i/o. Mmdi is now the largest allocated pool with 4,294 MB.
The following screenshot shows a graph of the Mmdi pool growth over 6 minutes, and the drivers associated with these memory allocations. The memory allocation trace was captured using xperf and WPA which are part of the Windows Performance Toolkit. The specific command used for the capture is as follows:
xperf -on PROC_THREAD+LOADER+POOL -stackwalk PoolAlloc+PoolFree+PoolAllocSession -BufferSize 4096 -MaxFile 4096 -FileMode Circular && timeout -1 && xperf -d H:\pool4.etl
Since both viofs.sys and winfsp-x64.dll are both associated with this pool growth, I am not sure whether this suspected memory leak is caused by Virtio-fs or WinFsp, so we have filed bug reports in both github repos. The Virtio-fs bug report can be found here.
The text was updated successfully, but these errors were encountered: