[PATCH] Implement -XX:+BindGCTaskThreadsToCPUs for Linux (original) (raw)

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

David

Thanks, Roman

Thanks, David On 25/07/2012 9:06 PM, Roman Kennke wrote: I implemented the other two missing functions in oslinux.cpp (distributeprocesses() and bindtoprocessor() ) 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 ossolaris.cpp. In particular assigndistribution() is almost 1:1 copy (except for the type diff processort 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 pthreadgetaffinitynp() does not work, it seems likely that the following call to pthreadsetaffinitynp() 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/linuxgcworkers/webrev.00/ Kind regards, Roman

More information about the hotspot-dev mailing list