[PATCH] Implement -XX:+BindGCTaskThreadsToCPUs for Linux

[David Holmes]

Hi Ben,

On 26/07/2012 11:29 PM, Ben Evans wrote:
> Hi David,
>
> Could you expand a bit on why you feel processor binding is problematic?

Because there are a number of API that impact what processors are 
available to a thread or process; they are non standard (ie platform 
specific) and the interactions between them is not always clear.

> In the low-latency space at least, this is a topic which often comes up.
> Having a view from the platform implementors as to why Java seems to be
> lacking compared to alternatives would be very useful.

Processor binding APIs have been proposed as part of the next real-time 
spec (JSR-282) and was also suggested for Java SE. But it is a difficult 
API to provide in a general way due to the different underlying 
mechanisms that can provide/constrain available processors. The simplest 
form of the API is "bind the current thread to the current processor" 
but that can be done by a simple native call for those specialized 
contexts that require it.

There is also concern that using process/thread binding effectively is a 
difficult task to get right, but very easy to get wrong.

David

> Thanks,
>
> Ben
>
> On Thu, Jul 26, 2012 at 5:52 AM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>     Hi Roman,
>
>     Processor binding is a problematic area in general. Copying what
>     Solaris does is probably harmless but not necessarily useful - and
>     the Solaris implementation is likely incomplete in itself (as there
>     are three mechanisms for constraining available CPUs: process
>     binding, processor sets and resource pools (which the VM is
>     generally ignorant of).
>
>     Do you have a motivating usecase for implementing this?
>
>     Thanks,
>     David
>
>
>     On 25/07/2012 9:06 PM, Roman Kennke wrote:
>
>         I implemented the other two missing functions in os_linux.cpp
>         (distribute_processes() and bind_to_processor() ) which implement
>         support for the -XX:+BindGCTaskThreadsToCPUs option (together
>         with -XX:
>         +UseParallelGC), which distributes&  binds GC worker threads to
>
>         different processors.
>
>         The implementation is adopted from os_solaris.cpp. In particular
>         assign_distribution() is almost 1:1 copy (except for the type diff
>         processor_t vs. uint). It could be worth extracting this into a
>         shared
>         method, but on the other hand, there is potential for divergence
>         (for
>         example, for NUMA support. See my related question here:
>         http://mail.openjdk.java.net/__pipermail/hotspot-gc-dev/2012-__July/004751.html
>         <http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2012-July/004751.html>
>         ).
>
>         Just like the implementation for Solaris, we first check if we are
>         running in a CPU set, and take this as a basis. I did not
>         implement the
>         other case though, it seems like a really rare fallback
>         (processes that
>         do not have any particular processor affinity return affinity
>         with all
>         processors set). Plus, if that call to pthread_getaffinity_np()
>         does not
>         work, it seems likely that the following call to
>         pthread_setaffinity_np() doesn't work either (because lack of
>         permissions or lack of support in the kernel or such). Please let me
>         know if you think it's worth to implement this case anyway and
>         use the
>         set of all online processors then.
>
>         Opinions about that patch?
>
>         http://cr.openjdk.java.net/~__rkennke/linux_gc_workers/__webrev.00/
>         <http://cr.openjdk.java.net/~rkennke/linux_gc_workers/webrev.00/>
>
>         Kind regards,
>         Roman
>
>
>