When libnxz suspects a VAS window might be suspended, it tries to open a
new one. But since the kernel does not allow the creation of new windows
while there are still suspended ones, libnxz has to close its existing
window before opening the new one.
This causes problems when a window is shared by multiple threads,
because one thread may issue a paste request on the window's associated
memory address, but it may not be valid anymore because a parallel
thread has already munmap'd it.
To avoid this problem every window now has a read-write lock and threads
are required to lock it first before performing any action on the
window, like reopening it or issuing a paste.
I ran compdecomp_th on PowerVM (100 threads) and baremetal (1000 threads) and couldn't detect any significant performance penalty.
This PR is intended to fix the following issue: https://github.com/libnxz/power-gzip/blob/3d08904a072d76f80a6229cb94847a43fc3fe58a/lib/gzip_vas.c#L371-L372
When libnxz suspects a VAS window might be suspended, it tries to open a new one. But since the kernel does not allow the creation of new windows while there are still suspended ones, libnxz has to close its existing window before opening the new one.
This causes problems when a window is shared by multiple threads, because one thread may issue a paste request on the window's associated memory address, but it may not be valid anymore because a parallel thread has already munmap'd it.
To avoid this problem every window now has a read-write lock and threads are required to lock it first before performing any action on the window, like reopening it or issuing a paste.
I ran
compdecomp_thon PowerVM (100 threads) and baremetal (1000 threads) and couldn't detect any significant performance penalty.