[PATCH] Implement -XX:+BindGCTaskThreadsToCPUs for Linux
david.holmes at oracle.com
Thu Jul 26 06:19:06 PDT 2012
On 26/07/2012 11:03 PM, Roman Kennke wrote:
> Am Donnerstag, den 26.07.2012, 22:52 +1000 schrieb David Holmes:
>> 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?
> Not really.
> Andrew Hughes found those missing methods and I thought I'd take a look
> at them, in order to get me started on hotspot, and to poke around the
> code and see how it worked (the code is fairly simple...).
> Initially I thought it could be helpful for assuring that each GC worker
> runs on a different CPU, but I am not so sure anymore, because it might
> undo NUMA benefits (see my related question on hotspot-gc-dev) and maybe
> the system's scheduler probably can do a better job of distributing the
> work. I haven't tested yet if the change gives us any benefit, I wanted
> to do this soon and thought I'd throw out the code for discussion. (And
> your comments seem to support my concerns...)
I don't subscribe to the GC list so haven't see the discussion, but as
you can guess there's been no motivation for implementing these
functions on linux :)
>> 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