<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 24, 2018 at 5:34 PM, Danil Zagoskin <span dir="ltr"><<a href="mailto:z@gosk.in" target="_blank">z@gosk.in</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><font face="monospace, monospace">-    2.57%     0.02%  31_scheduler     beam.smp                            [.] process_main  </font></div><div><font face="monospace, monospace">   - 2.55% process_main</font></div><div><font face="monospace, monospace">      - 2.43% erts_schedule </font></div><div><font face="monospace, monospace">         - 2.26% erts_port_task_execute</font></div><div><font face="monospace, monospace">            - 2.25% packet_inet_input.isra.31</font></div><div><font face="monospace, monospace">               - 2.05% driver_realloc_binary</font></div><div><font face="monospace, monospace">                  - 2.05% realloc_thr_pref</font></div><div><font face="monospace, monospace">                       1.87% __memmove_avx_unaligned_erms</font></div><div><br><font face="arial, helvetica, sans-serif">That's 40-core Xeon E5-2640</font><span style="font-family:arial,helvetica,sans-serif">, so 2.5% on a single scheduler is kind of 100%</span></div><div><font face="arial, helvetica, sans-serif">Also it's Linux kernel 4.9</font><br><br><br><font face="arial, helvetica, sans-serif">On a machine with kernel 4.13 and quad-core Xeon E31225 on a half of E5's load we have:</font><br><div><font face="monospace, monospace">-   16.11%     0.10%  1_scheduler      beam.smp                       [.] erts_schedule </font></div><div><font face="monospace, monospace">   - 16.01% erts_schedule</font></div><div><font face="monospace, monospace">      - 13.62% erts_port_task_execute </font></div><div><font face="monospace, monospace">         - 13.11% packet_inet_input.isra.31</font></div><div><font face="monospace, monospace">            - 11.37% driver_realloc_binary</font></div><div><font face="monospace, monospace">               - 11.33% realloc_thr_pref </font></div><div><font face="monospace, monospace">                  - 10.50% __memcpy_avx_unaligned </font></div><div><font face="monospace, monospace">                       5.06% __memcpy_avx_unaligned </font></div><div><font face="monospace, monospace">                     + 1.04% page_fault</font></div><div><font face="monospace, monospace">                    0.66% do_erts_alcu_realloc.<wbr>constprop.31</font></div><div><font face="monospace, monospace">            + 0.79% 0x108f3</font></div><div><font face="monospace, monospace">              0.55% driver_deliver_term </font></div><div><font face="monospace, monospace">        1.30% sched_spin_wait</font></div></div><div><font face="monospace, monospace"><br></font></div><div><font face="arial, helvetica, sans-serif">Seems like kernel version may change a lot, will run more tests.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">But it seems like memory operations are <span style="color:rgb(34,34,34);font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">unaligned which could be not very efficient.</span></font></div></div></blockquote><div><br></div><div>I'm not able to re-produce your benchmark, for some reason I don't get the load that you get.</div><div><br></div><div>Anyways, I stared a bit at the code and you get a lot of realloc that move, which is not good at all. Something that caught my eye was that the recbuf is 2 MB, while the packets you receive are a lot smaller. One of the side-effects of setting a large recbuf is that the user space buffer is also increased to the same value. I don't think you want this to happen in your case. What happens if you set buffer to the MTU?</div><div><br></div><div>Why would changing the user buffer size effect performance? Well, the udp read is done into the user-space buffer of the given size. When that size is 2 MB it is placed by erts_alloc inside a SBC (single block carrier). Then later when is it known how much data was actually received, a realloc is made of the 2 MB buffer to the size of the received data. This moves the data across the SBC border to the MBS (multi block carrier) and the realloc will have to copy the data in the binary. So by lowering the user-space buffer to be small enough to be placed in the MBC from the start, the move in realloc should disappear. That is if my theory is correct.<br></div><div><br></div><div>Lukas</div></div></div></div>