[PATCH] Implement -XX:+BindGCTaskThreadsToCPUs for Linux

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




More information about the hotspot-dev mailing list