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

Roman Kennke rkennke at redhat.com
Thu Jul 26 06:03:20 PDT 2012

Am Donnerstag, den 26.07.2012, 22:52 +1000 schrieb David Holmes:

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?

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

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