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

David Holmes david.holmes at oracle.com
Thu Jul 26 07:56:09 PDT 2012

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 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 <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/ <http://cr.openjdk.java.net/~rkennke/linuxgcworkers/webrev.00/> Kind regards, Roman

More information about the hotspot-dev mailing list