[concurrency-interest] On park and unpark

Andrig Miller anmiller at redhat.com
Tue Sep 5 20:47:48 EDT 2017


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.

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.

The issue eventually was just closed as "WON'T FIX".  Looked more like,
"CAN'T FIX" to me.

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.

Andy



On Tue, Sep 5, 2017 at 2:56 PM, David Holmes <davidcholmes at aapt.net.au>
wrote:

> Hi Andy,
>
>
>
> Can you elaborate further on this issue?
>
>
>
> 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.
>
>
>
> Thanks,
>
> David
>
>
>
> *From:* Concurrency-interest [mailto:concurrency-interest-
> bounces at cs.oswego.edu] *On Behalf Of *Andrig Miller
> *Sent:* Wednesday, September 6, 2017 3:45 AM
> *To:* Nathan and Ila Reynolds <nathanila at gmail.com>
> *Cc:* Concurrency-interest <concurrency-interest at cs.oswego.edu>
> *Subject:* Re: [concurrency-interest] On park and unpark
>
>
>
> 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%.
>
>
>
> To my knowledge, the kernel engineers have never been able to come up with
> a way to fix this issue.
>
>
>
> Andy
>
>
>
> On Fri, Aug 25, 2017 at 10:49 AM, Nathan and Ila Reynolds <
> nathanila at gmail.com> wrote:
>
> 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.
>
> For the blocking case, I would guess there would not be much difference in
> performance.
>
> I recommend running some microbenchmark tests for the non-blocking case
> (i.e. unpark() before park()).  You might see a CPU performance gain.
>
> -Nathan
>
>
>
> On 8/25/2017 10:28 AM, Doug Lea wrote:
>
> On 08/25/2017 11:12 AM, Andrew Haley wrote:
>
> On 25/08/17 12:12, Doug Lea wrote:
>
> BTW, on linux, it should be more efficient to implement using
> Futex instead of the current scheme based on original Solaris
> version. But no one has ever volunteered to do this.
>
> I've done it, and could not measure any difference.
>
> Well, it should still save a few electrons (or millions, across
> deployments), so still seems to be the Right Thing to do.
>
> -Doug
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
> --
> -Nathan
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
>
>
> --
>
> Andrig (Andy) T. Miller
>
> Global Platform Director, Middleware
>
> Red Hat, Inc.
>



-- 
Andrig (Andy) T. Miller
Global Platform Director, Middleware
Red Hat, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20170905/0bdd92d8/attachment-0001.html>


More information about the Concurrency-interest mailing list