<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 26, 2021, 22:05 Maximilian Böther <<a href="mailto:maximilian.boether@student.hpi.de">maximilian.boether@student.hpi.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br>
<br>
I am investigating an application that writes random data in fixed-size <br>
chunks (e.g. 4k) to random locations in a large buffer file. I have <br>
several processes (not threads) doing that, each process has its own <br>
buffer file assigned.<br>
<br>
If I use mmap+msync to write and persist data to disk, I see a <br>
performance spike for 16 processes, and a performance drop for more <br>
threads (32 processes). The CPU has 32 logical cores in total, and we <br>
are not CPU bound.<br>
<br>
If I use open+write+fsync, I do not see such a spike, instead a <br>
performance plateau (and mmap is slower than open/write).<br>
<br>
I've read multiple times [1,2] that both mmap and msync can take locks. <br>
With vtune, I analyzed that we are indeed spinlocking, and spending the <br>
most time in clear_page_erms and xas_load functions.<br>
<br>
However, when reading the source code for msync [3], I cannot understand <br>
whether these locks are global or per-file. The paper [2] states that <br>
the locks are on radix-trees within the kernel that are per-file, <br>
however, as I do observe some spinlocks in the kernel, I believe that <br>
some locks may be global, as I have one file per process.<br>
<br>
Do you have an explanation on why we have such a spike at 16 processes <br>
for mmap and input on the locking behavior of msync?<br>
<br>
Thank you!<br>
<br>
Best,<br>
Maximilian Böther<br>
<br>
[1] <br>
<a href="https://kb.pmem.io/development/100000025-Why-msync-is-less-optimal-for-persistent-memory/" rel="noreferrer noreferrer" target="_blank">https://kb.pmem.io/development/100000025-Why-msync-is-less-optimal-for-persistent-memory/</a> <br>
- I know it's about PMem, but the lock argument is important<br>
<br>
[2] Optimizing Memory-mapped I/O for Fast Storage Devices, Papagiannis <br>
et al., ATC '20<br>
<br>
[3] <a href="https://elixir.bootlin.com/linux/latest/source/mm/msync.c" rel="noreferrer noreferrer" target="_blank">https://elixir.bootlin.com/linux/latest/source/mm/msync.c</a><br>
<br>
_______________________________________________<br>
Kernelnewbies mailing list<br>
<a href="mailto:Kernelnewbies@kernelnewbies.org" target="_blank" rel="noreferrer">Kernelnewbies@kernelnewbies.org</a><br>
<a href="https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies" rel="noreferrer noreferrer" target="_blank">https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbi</a>es<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Is it NUMA?</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>