Linux Kernel - msync 锁定行为

Question

I am investigating an application that writes random data in fixed-size chunks (eg 4k) to random locations in a large buffer file. I have several processes (not threads) doing that, each process has its own buffer file assigned.

If I use mmap+msync to write and persist data to disk, I see a performance spike for 16 processes, and a performance drop for more threads (32 processes).

If I use open+write+fsync, I do not see such a spike, instead a performance plateau (and mmap is slower than open/write).

I've read multiple times [1,2] that both mmap and msync can take locks. With vtune, I analyzed that we are indeed spinlocking, and spending the most time in clear_page_erms and xas_load functions.

However, when reading the source code for msync [3], I cannot understand whether these locks are global or per-file. The paper [2] states that the locks are on radix-trees within the kernel that are per-file, however, as I do observe some spinlocks in the kernel, I believe that some locks may be global, as I have one file per process.

Do you have an explanation on why we have such a spike at 16 processes for mmap and input on the locking behavior of msync?

Thank you!

Best, Maximilian

[1] https://kb.pmem.io/development/100000025-Why-msync-is-less-optimal-for-persistent-memory/

[2] Optimizing Memory-mapped I/O for Fast Storage Devices, Papagiannis et al., ATC '20

[3] https://elixir.bootlin.com/linux/latest/source/mm/msync.c

Answer 1

In the 4.19 kernel source, the current task keeps its own mm_struct, which contains a single semaphore used to arbitrate accesses to all memory regions being synced. All of the threads in a process acting on one of your buffer files will therefore take this semaphore, operate on some region(s) of the file, and release the semaphore.

While I can't rationalise the exact number of 16 processes where you hit your performance cliff, clearly when you use mmap() you are forcing entry into the msync(M_SYNC) code section for VM_SHARED. This invokes vfs_fsync_range() and guarantees actual synchronous disk I/O will happen, which is going to generally slow down the show: it does not allow advantageous grouping of I/Os for economy and tends to maximise the actual time spent waiting for disk I/O to complete.

To avoid this, ensure that each thread in your process manages a dedicated subset of 4K chunks in the buffer file, avoids mmap() on the buffer file, and schedules async I/O. So long as you avoid mmap() on the buffer file itself , each thread will be alone in writing (safely, if you design well) to its own section of the buffer file. You will therefore be able to specify all of your I/O to be asynchronous, which should allow better aggregation and significantly improve your application's performance ie avoid that cliff at 16 processes or whatever the number ends up being. Obviously, you'll still have to ensure that any thread writing to one of its chunks either completes that write or has not yet begun it (and drops any request(s) to do so) if a request for another write to the same chunk comes along.