[PATCH] Implement -XX:+BindGCTaskThreadsToCPUs for Linux
david.holmes at oracle.com
Thu Jul 26 05:52:39 PDT 2012
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?
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 ).
> 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?
> Kind regards,
More information about the hotspot-dev