<div dir="ltr"><div class="gmail_default" style="font-size:large">It took some digging but I found the original bugzilla for this issue.  It was the JVM running in a KVM guest, on RHEL 6.4.  Unfortunately, all the details are mostly private, because it originated with a Red Hat customer case.</div><div class="gmail_default" style="font-size:large"><br></div><div class="gmail_default" style="font-size:large">Having said that, the issue seems to be related to how the paravirtualized kernel deals with interrupts and scheduling as a result of the futex call.  The interesting thing here, is that no one was able to actually solve it with experimental kernel patches.  Lot's of things were tried, but none truly succeeded.</div><div class="gmail_default" style="font-size:large"><br></div><div class="gmail_default" style="font-size:large">The issue eventually was just closed as "WON'T FIX".  Looked more like, "CAN'T FIX" to me.</div><div class="gmail_default" style="font-size:large"><br></div><div class="gmail_default" style="font-size:large">So, it is an isolated issue, and perhaps it doesn't even happen anymore, but since I remembered this issue, I wanted to let everyone know.</div><div class="gmail_default" style="font-size:large"><br></div><div class="gmail_default" style="font-size:large">Andy</div><div class="gmail_default" style="font-size:large"><br></div><div class="gmail_default" style="font-size:large"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 5, 2017 at 2:56 PM, David Holmes <span dir="ltr"><<a href="mailto:davidcholmes@aapt.net.au" target="_blank">davidcholmes@aapt.net.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_8270874076099347041WordSection1"><p class="MsoNormal">Hi Andy,<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Can you elaborate further on this issue?<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">But given futex is also the underpinning of the pthread mutex/condvar, wouldn’t you see the same slow down in either case? Or is there something specific about calling futex API directly from the JVM.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Thanks,<u></u><u></u></p><p class="MsoNormal">David<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt"><div><div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal"><b>From:</b> Concurrency-interest [mailto:<a href="mailto:concurrency-interest-bounces@cs.oswego.edu" target="_blank">concurrency-interest-<wbr>bounces@cs.oswego.edu</a>] <b>On Behalf Of </b>Andrig Miller<br><b>Sent:</b> Wednesday, September 6, 2017 3:45 AM<br><b>To:</b> Nathan and Ila Reynolds <<a href="mailto:nathanila@gmail.com" target="_blank">nathanila@gmail.com</a>><br><b>Cc:</b> Concurrency-interest <<a href="mailto:concurrency-interest@cs.oswego.edu" target="_blank">concurrency-interest@cs.<wbr>oswego.edu</a>><span class=""><br><b>Subject:</b> Re: [concurrency-interest] On park and unpark<u></u><u></u></span></p></div></div><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal"><span style="font-size:18.0pt">I know of a futex performance issue that remains in the kernel.  Whenever futex is called when the JVM is running in a virtual machine it performs very poorly.  In the particular case that made me aware of this issue, the slowdown was 50%.<u></u><u></u></span></p></div><div><div class="h5"><div><p class="MsoNormal"><span style="font-size:18.0pt"><u></u> <u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:18.0pt">To my knowledge, the kernel engineers have never been able to come up with a way to fix this issue.<u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:18.0pt"><u></u> <u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:18.0pt">Andy<u></u><u></u></span></p></div></div></div></div><div><div class="h5"><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">On Fri, Aug 25, 2017 at 10:49 AM, Nathan and Ila Reynolds <<a href="mailto:nathanila@gmail.com" target="_blank">nathanila@gmail.com</a>> wrote:<u></u><u></u></p><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><p class="MsoNormal">Several years ago, I saw Linux futex perform poorly in the kernel.  Futex was getting a bad rap by others as well.  In my experience, the kernel would spend a lot of CPU time dealing with futexes.  I do not remember the circumstances that cause this scenario.  So, I recommend proceeding with caution and lots of testing.  Perhaps, this caution is not warranted and the problem was fixed in the kernel.<br><br>For the blocking case, I would guess there would not be much difference in performance.<br><br>I recommend running some microbenchmark tests for the non-blocking case (i.e. unpark() before park()).  You might see a CPU performance gain.<br><br>-Nathan<u></u><u></u></p><div><div><p class="MsoNormal"><br><br>On 8/25/2017 10:28 AM, Doug Lea wrote:<u></u><u></u></p><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><p class="MsoNormal">On 08/25/2017 11:12 AM, Andrew Haley wrote:<u></u><u></u></p><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><p class="MsoNormal">On 25/08/17 12:12, Doug Lea wrote:<u></u><u></u></p><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><p class="MsoNormal">BTW, on linux, it should be more efficient to implement using<br>Futex instead of the current scheme based on original Solaris<br>version. But no one has ever volunteered to do this.<u></u><u></u></p></blockquote><p class="MsoNormal">I've done it, and could not measure any difference.<u></u><u></u></p></blockquote><p class="MsoNormal">Well, it should still save a few electrons (or millions, across<br>deployments), so still seems to be the Right Thing to do.<br><br>-Doug<br>______________________________<wbr>_________________<br>Concurrency-interest mailing list<br><a href="mailto:Concurrency-interest@cs.oswego.edu" target="_blank">Concurrency-interest@cs.<wbr>oswego.edu</a><br><a href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank">http://cs.oswego.edu/mailman/<wbr>listinfo/concurrency-interest</a><u></u><u></u></p></blockquote><p class="MsoNormal"><u></u> <u></u></p></div></div><p class="MsoNormal"><span class="m_8270874076099347041hoenzb"><span style="color:#888888">-- </span></span><span style="color:#888888"><br><span class="m_8270874076099347041hoenzb">-Nathan</span></span><u></u><u></u></p><div><div><p class="MsoNormal"><br><br>______________________________<wbr>_________________<br>Concurrency-interest mailing list<br><a href="mailto:Concurrency-interest@cs.oswego.edu" target="_blank">Concurrency-interest@cs.<wbr>oswego.edu</a><br><a href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank">http://cs.oswego.edu/mailman/<wbr>listinfo/concurrency-interest</a><u></u><u></u></p></div></div></blockquote></div><p class="MsoNormal"><br><br clear="all"><u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p></div><p class="MsoNormal">-- <u></u><u></u></p><div><div><div><div><div><div><p class="MsoNormal"><span style="font-size:13.5pt">Andrig (Andy) T. Miller</span><u></u><u></u></p></div><p class="MsoNormal"><span style="font-size:13.5pt">Global Platform Director, Middleware</span><u></u><u></u></p></div><p class="MsoNormal"><span style="font-size:13.5pt">Red Hat, Inc.</span><u></u><u></u></p></div></div></div></div></div></div></div></div></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div><font size="4">Andrig (Andy) T. Miller<br></font></div><font size="4">Global Platform Director, Middleware<br></font></div><font size="4">Red Hat, Inc.</font><br></div></div></div></div>
</div>