[PATCH] Implement -XX:+BindGCTaskThreadsToCPUs for Linux

[David Holmes]

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 :)

David

> Thanks,
> Roman
>
>>
>> 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 ).
>>>
>>> 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/
>>>
>>> Kind regards,
>>> Roman
>>>
>>>
>
>