RFR: 6515172: Runtime.availableProcessors() ignores Linux taskset command

[Thomas Stüfe]

Hi David,

I may be doing this wrong, but I do not get this to work for me (ubuntu
14.4).

I built hs-rt with your patch. I am running a simple loop with
Runtime.availableProcessors(). I change affinity with taskset and would
expect output to change, but nothing changes.

java command line: ../images/jdk/bin/java -Xlog:os=trace test
taskset command:  taskset -p 0x1 <pid>

Output:

proc: 8
[73,525s][trace  ][os] active_processor_count: using static path -
configured processors: 8
[73,525s][trace  ][os] active_processor_count: sched_getaffinity processor
count: 8
proc: 8
...

Kind Regards, Thomas




On Fri, Jan 22, 2016 at 9:06 AM, David Holmes <david.holmes at oracle.com>
wrote:

> First a special thanks to Martin Buchholz for his input, feedback,
> critique and raising awareness of how non-simple this issue is.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-6515172
> webrev: http://cr.openjdk.java.net/~dholmes/6515172/webrev/
>
> Basic problem:
>   processors available for use <= processors online <= processors
> configured
>
> but we always returned the number of online processors.
>
> Solution is simple in its basic form: use sched_getaffinity to get the
> scheduling affinity mask and count the number of available processors.
>
> Details are complicated by the desire to handle very large processor
> systems. See the bug report for lots of detailed discussions and references.
>
> Testing:
>  - new test that verifies behaviour when running under taskset
>  - diagnostic hook injection (UseNewCodeN) to enable testing of all code
> paths (one hook is left in for non-product to allow easy testing of the
> dynamic path)
>  - JPRT
>
> Compatability issues:
> - the system code we're using now is at least 5 years old so distro's
> older than that (which are not officially supported) may not work
> - anyone already running under a processor constrained environment (like
> Docker) and using availableProcessor() to "size" things, will find that
> size has now changed. We do not expect this to be a problem - on the
> contrary we expect Docker users to want the new behaviour.
>
> Thanks,
> David
>