Page MenuHomePhabricator

pawosm01 (Paul Osmialowski)
User

Projects

User does not belong to any projects.

User Details

User Since
Feb 5 2016, 9:28 AM (200 w, 6 d)

Recent Activity

May 16 2019

pawosm01 committed rOMP360890: Fix hwloc topology traversal code unable to handle situation where L2 cache is….
Fix hwloc topology traversal code unable to handle situation where L2 cache is…
May 16 2019, 6:16 AM
pawosm01 committed rG0732fcc7d5a4: Fix hwloc topology traversal code unable to handle situation where L2 cache is… (authored by pawosm01).
Fix hwloc topology traversal code unable to handle situation where L2 cache is…
May 16 2019, 6:16 AM
pawosm01 committed rL360890: Fix hwloc topology traversal code unable to handle situation where L2 cache is….
Fix hwloc topology traversal code unable to handle situation where L2 cache is…
May 16 2019, 6:16 AM
pawosm01 closed D61796: Fix hwloc topology traversal code unable to handle situation where L2 cache is common for the packages.
May 16 2019, 6:16 AM · Restricted Project, Restricted Project

May 11 2019

pawosm01 added reviewers for D61796: Fix hwloc topology traversal code unable to handle situation where L2 cache is common for the packages: AndreyChurbanov, jlpeyton.
May 11 2019, 3:31 PM · Restricted Project, Restricted Project

May 10 2019

pawosm01 created D61796: Fix hwloc topology traversal code unable to handle situation where L2 cache is common for the packages.
May 10 2019, 11:48 AM · Restricted Project, Restricted Project

Jan 21 2019

pawosm01 closed D55078: Add omp_pause_resource* API.
Jan 21 2019, 8:05 AM · Restricted Project
pawosm01 accepted D55078: Add omp_pause_resource* API.

It's ok, works for me now.

Jan 21 2019, 8:03 AM · Restricted Project
pawosm01 accepted D57017: Fixed https://reviews.llvm.org/D55078.
Jan 21 2019, 7:24 AM · Restricted Project
pawosm01 requested changes to D55078: Add omp_pause_resource* API.
Jan 21 2019, 7:00 AM · Restricted Project
pawosm01 reopened D55078: Add omp_pause_resource* API.

Please correct.

Jan 21 2019, 6:59 AM · Restricted Project
pawosm01 added a comment to D55078: Add omp_pause_resource* API.

This commi causes Flang unit tests to fail.

Jan 21 2019, 6:59 AM · Restricted Project

Nov 7 2018

pawosm01 added a comment to D40358: Use hyperbarrier by default on all architectures.

Not much I'm able to say. The error is the malformed integer value resulting in incorrect computation result, more often on AArch64, less often on x86_64, both architectures running under Linux. The code does something unusual so I'm not surprised no one faced this before. Also keep in mind that I would never find it if hyperbarriers weren't introduced for all architectures.

Nov 7 2018, 7:13 AM
pawosm01 added a comment to D40358: Use hyperbarrier by default on all architectures.

I need to contact someone who introduced KMP_REVERSE_HYPER_BAR implementation (unfortunately, it was added here in a huge collective commit years ago, Tue Oct 7 16:25:50 2014).
I have a piece of proprietary code that stopped to fail on AArch64 after I reverted D40358. Digging deeper I found out that it's not the problem with hyperbariers per se. As I undefined KMP_REVERSE_HYPER_BAR, the problem went away. What else I found is that the problem can be reproduced on x86_64 too, only less frequent (once per `for i in seq 1 1000; do``` execution). As I'd have to spend a time to figure out the logic behind it and verify its validity, in the meantime, can someone familiar with this code have a look at it and confirm reverse implementation is sane?

Nov 7 2018, 5:37 AM

Oct 5 2018

pawosm01 added a comment to D51232: [OpenMP] Initial implementation of OMP 5.0 Memory Management routines.

This commit is bit damaging for those who want to use libomp.a for -static built applications. As KMP_DYNAMIC_LIB is hardcoded to 1 in kmp_config.h.cmake, dlopen will always be used causing following link-time warning:

warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

This makes virtually impossible to copy libomp.a across various Linux boxes or shipping libomp.a in binary libomp packages addressed to various Linux systems.

Oct 5 2018, 6:00 AM · Restricted Project

Sep 7 2018

pawosm01 accepted D51694: Fix for https://bugs.llvm.org/show_bug.cgi?id=38839.
Sep 7 2018, 5:04 AM

Sep 5 2018

pawosm01 added inline comments to D51694: Fix for https://bugs.llvm.org/show_bug.cgi?id=38839.
Sep 5 2018, 11:27 AM

Jul 25 2018

pawosm01 accepted D49802: PR30734: Remove __kmp_ft_page_allocate().
Jul 25 2018, 9:19 AM

Feb 9 2018

pawosm01 added a comment to D43115: [OMPT] Fix inconsistent testcases.

OMPT test cases all pass after that change.

Feb 9 2018, 5:20 AM
pawosm01 requested changes to D43115: [OMPT] Fix inconsistent testcases.

Can't compile this

Feb 9 2018, 5:09 AM

Jan 11 2018

pawosm01 added a comment to D41817: [OMPT] Enable OMPT on 32-bit ARM machines.

I suspect proposed change in kmp_gsupport.cpp might of confused you (as I check only for arch but not for the compiler). Note that gsupport (GOMP interface for libomp) must be compatible with what GCC-compiled programs do, otherwise compiling libomp with clang and running test cases compiled with GCC would lead to confusing inconsistency.

Jan 11 2018, 2:59 AM · Restricted Project
pawosm01 added a comment to D41817: [OMPT] Enable OMPT on 32-bit ARM machines.

Ahh, I didn't say it isn't working, but I also didn't explicitly said that: when libomp+OMPT is built with clang on 32-bit ARM, all of OMPT test cases pass iff they are compiled with clang.
The problem is on 32-bit ARM and GCC.

Jan 11 2018, 12:25 AM · Restricted Project

Jan 10 2018

pawosm01 added a comment to D41817: [OMPT] Enable OMPT on 32-bit ARM machines.

Ok, relevant line changed. I didn't notice that although kmp_platform.h (where KMP_ARCH_ARM is defined) is included from callback.h, kmp_os.h where KMP_COMPILER_GCC is defined is not included.
Also note that both clang++ and g++ define __GNUC__ hence full check for GNU C++ compiler looks as follows:

#if defined(__GNUC__) && !defined(__clang__)
#warning this is a GNU compiler
#else
#warning this is NOT a GNU compiler
#endif
Jan 10 2018, 1:40 PM · Restricted Project
pawosm01 added a comment to D41817: [OMPT] Enable OMPT on 32-bit ARM machines.

Guys, I can think of approach as follows, but fixing all relevant lit tests to make FileCheck directives aware of relevant architecture+compiler combinations is beyond my imagination:

Jan 10 2018, 8:19 AM · Restricted Project

Jan 9 2018

pawosm01 added a comment to D41817: [OMPT] Enable OMPT on 32-bit ARM machines.

Does a Clang built runtime work for GCC? In particular, do all tests pass when building with Clang but adding -DOPENMP_TEST_C_COMPILER=gcc -DOPENMP_TEST_CXX_COMPILER=g++?

Jan 9 2018, 11:44 PM · Restricted Project
pawosm01 added a comment to D41817: [OMPT] Enable OMPT on 32-bit ARM machines.

I really like this message that proposed patch causes on ARM + gcc when someone's trying to set -DLIBOMP_OMPT_SUPPORT=ON:

CMake Error at runtime/cmake/LibompUtils.cmake:27 (message):
  LIBOMP: OpenMP Tools Interface requested but not available in this
  implementation
Call Stack (most recent call first):
  runtime/CMakeLists.txt:316 (libomp_error_say)

This is more clean solution than passing NULL which effects in less pleasant failures.

Jan 9 2018, 2:40 PM · Restricted Project
pawosm01 updated the diff for D41817: [OMPT] Enable OMPT on 32-bit ARM machines.
Jan 9 2018, 10:05 AM · Restricted Project
pawosm01 added a comment to D41817: [OMPT] Enable OMPT on 32-bit ARM machines.

Nah, doing architecture && compiler doesn't seem to work. I've got some better idea.

Jan 9 2018, 10:04 AM · Restricted Project
pawosm01 added a comment to D41817: [OMPT] Enable OMPT on 32-bit ARM machines.

Found that __builtin_frame_address(1) gives wrong answer in __kmp_api_GOMP_parallel (a.k.a KMP_API_NAME_GOMP_PARALLEL as in kmp_gsupport.cpp). Then I've found out that this won't work with gcc: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60109
Status: RESOLVED WONTFIX
We can mark it UNSUPPORTED on arm32/gcc

Jan 9 2018, 5:00 AM · Restricted Project
pawosm01 committed rOMP322068: Fix type mismatch in omp_control_tool() implementation that makes it run….
Fix type mismatch in omp_control_tool() implementation that makes it run…
Jan 9 2018, 2:58 AM
pawosm01 committed rL322068: Fix type mismatch in omp_control_tool() implementation that makes it run….
Fix type mismatch in omp_control_tool() implementation that makes it run…
Jan 9 2018, 2:55 AM
pawosm01 closed D41854: [OMPT] Fix type mismatch in omp_control_tool() implementation that makes it run incorrectly on 32-bit machines.
Jan 9 2018, 2:55 AM · Restricted Project
pawosm01 added a comment to D41817: [OMPT] Enable OMPT on 32-bit ARM machines.

It's in https://reviews.llvm.org/D41854
Cheers

Jan 9 2018, 2:12 AM · Restricted Project
pawosm01 created D41854: [OMPT] Fix type mismatch in omp_control_tool() implementation that makes it run incorrectly on 32-bit machines.
Jan 9 2018, 2:12 AM · Restricted Project

Jan 8 2018

pawosm01 added a comment to D41817: [OMPT] Enable OMPT on 32-bit ARM machines.

It's kmp_gsupport.cpp issue I presume, was it ever tested on any 32-bit platform? I'll try to look at it through the day.

Jan 8 2018, 11:23 PM · Restricted Project
pawosm01 accepted D31600: KMP_HW_SUBSET extended with NUMA support when HWLOC enabled.
Jan 8 2018, 11:56 AM · Restricted Project
pawosm01 added a comment to D41817: [OMPT] Enable OMPT on 32-bit ARM machines.

The older gcc version the worse it gets, with 4.9.1-16ubuntu6 it's:

Jan 8 2018, 8:28 AM · Restricted Project
pawosm01 added a comment to D41817: [OMPT] Enable OMPT on 32-bit ARM machines.

I didn't even know these tests are allowed to be compiled with anything else than clang 6.0+...

Jan 8 2018, 8:24 AM · Restricted Project
pawosm01 added a comment to D31600: KMP_HW_SUBSET extended with NUMA support when HWLOC enabled.

what's the next step here?

Jan 8 2018, 5:42 AM · Restricted Project
pawosm01 added a comment to D41817: [OMPT] Enable OMPT on 32-bit ARM machines.

I did my tests on 32-bit dual-core ARMv7 Cortex-A9 machine. Just in case I also tested it on 64-bit 96-cores ARMv8.1 machine to make sure there are no regressions.

Jan 8 2018, 5:39 AM · Restricted Project
pawosm01 created D41817: [OMPT] Enable OMPT on 32-bit ARM machines.
Jan 8 2018, 5:36 AM · Restricted Project

Dec 23 2017

pawosm01 added a comment to D41508: [OMPT] Build runtime with OMPT support by default.

@Hahnfeld gosh, you're right and I don't work with 32-bit systems nowadays so I need to track down one of those still kept online. Being far from the office isn't helping, so it won't happen immediately.

Dec 23 2017, 5:06 AM
pawosm01 accepted D41508: [OMPT] Build runtime with OMPT support by default.

+1

Dec 23 2017, 2:22 AM

Dec 22 2017

pawosm01 committed rOMP321379: [OMPT] Add missing initialization in nested_lwt.c test case.
[OMPT] Add missing initialization in nested_lwt.c test case
Dec 22 2017, 11:25 AM
pawosm01 committed rL321379: [OMPT] Add missing initialization in nested_lwt.c test case.
[OMPT] Add missing initialization in nested_lwt.c test case
Dec 22 2017, 11:25 AM
pawosm01 closed D41542: [OMPT] Add missing initialization in nested_lwt.c test case.
Dec 22 2017, 11:25 AM
pawosm01 created D41542: [OMPT] Add missing initialization in nested_lwt.c test case.
Dec 22 2017, 4:33 AM

Dec 21 2017

pawosm01 committed rOMP321258: [AArch64] add required arch specific code for running OMPT test cases.
[AArch64] add required arch specific code for running OMPT test cases
Dec 21 2017, 4:36 AM
pawosm01 committed rL321258: [AArch64] add required arch specific code for running OMPT test cases.
[AArch64] add required arch specific code for running OMPT test cases
Dec 21 2017, 4:34 AM
pawosm01 closed D41482: AArch64: add required arch specific code for running OMPT test cases.
Dec 21 2017, 4:34 AM
pawosm01 created D41482: AArch64: add required arch specific code for running OMPT test cases.
Dec 21 2017, 1:29 AM

Dec 13 2017

pawosm01 committed rOMP320593: [AArch64] fix an issue with older /proc/cpuinfo layout.
[AArch64] fix an issue with older /proc/cpuinfo layout
Dec 13 2017, 8:15 AM
pawosm01 committed rL320593: [AArch64] fix an issue with older /proc/cpuinfo layout.
[AArch64] fix an issue with older /proc/cpuinfo layout
Dec 13 2017, 8:13 AM
pawosm01 closed D41000: AArch64: fix cpuinfo issues.
Dec 13 2017, 8:13 AM · Restricted Project

Dec 10 2017

pawosm01 added a comment to D41000: AArch64: fix cpuinfo issues.

Example of old format layout (note that 'Processor :' and 'processor :' won't collide as we don't call strncasecmp()):

Dec 10 2017, 3:29 PM · Restricted Project

Dec 9 2017

pawosm01 updated the diff for D41000: AArch64: fix cpuinfo issues.
Dec 9 2017, 12:24 PM · Restricted Project

Dec 8 2017

pawosm01 added a comment to D40722: Add missing memory barrier for queuing locks.

I tried various number of threads with OMP_NUM_THREADS (in range between 4 and 96 on 96 cores dual socket ARMv8.1 machine, and between 2 and 4 on 4 cores single socket ARMv8 machine) and enforced affinity with OMP_PROC_BIND=spread, so I guess it answers your question.

Dec 8 2017, 7:51 AM
pawosm01 accepted D40722: Add missing memory barrier for queuing locks.

+1, although I ran this omp_single_copyprivate.c example in a loop 10000 times on two different AArch64 machines (ARMv8 and ARMv8.1) and didn't observe any hangs, before and after applying this patch.

Dec 8 2017, 6:55 AM

Dec 7 2017

pawosm01 created D41000: AArch64: fix cpuinfo issues.
Dec 7 2017, 11:10 PM · Restricted Project

Aug 10 2017

pawosm01 committed rL310670: OMP_PROC_BIND: better spread.
OMP_PROC_BIND: better spread
Aug 10 2017, 4:05 PM
pawosm01 closed D36510: OMP_PROC_BIND: better spread by committing rL310670: OMP_PROC_BIND: better spread.
Aug 10 2017, 4:05 PM · Restricted Project
pawosm01 updated the diff for D36510: OMP_PROC_BIND: better spread.

some words of explanation added, as requested.

Aug 10 2017, 10:01 AM · Restricted Project

Aug 9 2017

pawosm01 updated the diff for D36510: OMP_PROC_BIND: better spread.

couldn't build everywhere with that assertion.

Aug 9 2017, 11:46 PM · Restricted Project
pawosm01 added a comment to D36510: OMP_PROC_BIND: better spread.

Let me illustrate how current algorithm works for 96 cores (dual CPU) machine (stars are threads):

Aug 9 2017, 1:33 PM · Restricted Project
pawosm01 created D36510: OMP_PROC_BIND: better spread.
Aug 9 2017, 4:19 AM · Restricted Project

Apr 25 2017

pawosm01 accepted D32496: Fix Hwloc API Incompatibility.
Apr 25 2017, 10:41 AM

Apr 24 2017

pawosm01 requested changes to D31600: KMP_HW_SUBSET extended with NUMA support when HWLOC enabled.
Apr 24 2017, 10:20 AM · Restricted Project
pawosm01 reopened D31600: KMP_HW_SUBSET extended with NUMA support when HWLOC enabled.

Due to use of new enum constants (HWLOC_OBJ_NUMANODE, HWLOC_OBJ_PACKAGE) this code does not compile on most of the mainstream Linux distributions where pre 2.0 hwloc (-devel) is still provided:

Apr 24 2017, 10:18 AM · Restricted Project

Mar 23 2017

pawosm01 added a comment to D31071: GOMP compatibility: add missing OMP4.0 taskdeps handling code.

Setting all flags in both branches seemed to me as better expressing my intents, but I can change it if you insist.

I am not going to insist. I just find it odd to have a duplicate line of code, and the fact that it is the same in both if branches made me suspicious that there was bug lurking there. So, personally, I would find code like this clearer.

dep_list[i].len = 0U;
dep_list[i].flags.in = 1;
dep_list[i].flags.out = i<nout;
Mar 23 2017, 8:16 AM
pawosm01 committed rL298605: GOMP compatibility: add missing OpenMP4.0 task deps handling code.
GOMP compatibility: add missing OpenMP4.0 task deps handling code
Mar 23 2017, 8:15 AM
pawosm01 closed D31071: GOMP compatibility: add missing OMP4.0 taskdeps handling code by committing rL298605: GOMP compatibility: add missing OpenMP4.0 task deps handling code.
Mar 23 2017, 8:15 AM
pawosm01 added a comment to D31071: GOMP compatibility: add missing OMP4.0 taskdeps handling code.

Is "dep_list[i].flags.in = 1;" really supposed to be set in both of the if cases (lines 980 and 983)?
If so, can't we lift that out of the if?

Mar 23 2017, 6:34 AM
pawosm01 updated the diff for D31071: GOMP compatibility: add missing OMP4.0 taskdeps handling code.

now using gomp_flags

Mar 23 2017, 5:35 AM
pawosm01 added a comment to D31071: GOMP compatibility: add missing OMP4.0 taskdeps handling code.
Mar 23 2017, 4:50 AM

Mar 17 2017

pawosm01 created D31071: GOMP compatibility: add missing OMP4.0 taskdeps handling code.
Mar 17 2017, 4:22 AM

Mar 6 2017

pawosm01 committed rL297070: Add AArch64 support..
Add AArch64 support.
Mar 6 2017, 1:12 PM
pawosm01 closed D30644: [libomptarget] Add AArch64 support by committing rL297070: Add AArch64 support..
Mar 6 2017, 1:12 PM
pawosm01 created D30644: [libomptarget] Add AArch64 support.
Mar 6 2017, 4:41 AM

Feb 15 2017

pawosm01 accepted D25504: Fixes a memory leak related to task dependencies (patch from Alex Duran).
Feb 15 2017, 2:27 AM

Nov 19 2016

pawosm01 accepted D26860: Fix for D25504 - segfault because of double free()-ing in task deps shutdown code..

I tested this change for few hours running superlu_taskdep and strassen_taskdep on different number of cores. Didn't fail, so we can assume it solves the problem.

Nov 19 2016, 2:22 PM

Nov 16 2016

pawosm01 requested changes to D25504: Fixes a memory leak related to task dependencies (patch from Alex Duran).
Nov 16 2016, 11:02 AM
pawosm01 reopened D25504: Fixes a memory leak related to task dependencies (patch from Alex Duran).

Segfault at the fery first line of kmp_dephash_free_entries() while trying to dereference a pointer passed as a parameter. The pointer to memory allocated by kmp_fast_allocate() became invalid after __kmp_free_fast_memory() was called.

Nov 16 2016, 11:01 AM

Nov 1 2016

pawosm01 accepted D21196: Excluded untied tasks from task stealing constraint.
Nov 1 2016, 10:08 AM
pawosm01 accepted D26182: Fixed problem introduced by part of https://reviews.llvm.org/D21196..
Nov 1 2016, 8:34 AM

Oct 26 2016

pawosm01 added a comment to D21196: Excluded untied tasks from task stealing constraint.

I'm using libomp from latest git master built using clang and gcc (tried both builds with the same result)

Oct 26 2016, 11:50 AM
pawosm01 added a comment to D21196: Excluded untied tasks from task stealing constraint.

I don't really know what to do with this, I guess the original author knows best what's next...

Oct 26 2016, 11:25 AM

Oct 22 2016

pawosm01 requested changes to D21196: Excluded untied tasks from task stealing constraint.
Oct 22 2016, 4:19 AM
pawosm01 reopened D21196: Excluded untied tasks from task stealing constraint.

Regression found. See comment in line 1754.

Oct 22 2016, 4:19 AM

Sep 30 2016

pawosm01 committed rL282965: [cmake] Fix for a bug https://llvm.org/bugs/show_bug.cgi?id=30489 "Cannot build….
[cmake] Fix for a bug https://llvm.org/bugs/show_bug.cgi?id=30489 "Cannot build…
Sep 30 2016, 3:14 PM
pawosm01 closed D24959: [cmake] Fix for a bug https://llvm.org/bugs/show_bug.cgi?id=30489 "Cannot build with -DLIBOMP_FORTRAN_MODULES=True" by committing rL282965: [cmake] Fix for a bug https://llvm.org/bugs/show_bug.cgi?id=30489 "Cannot build….
Sep 30 2016, 3:14 PM

Sep 28 2016

pawosm01 updated the diff for D24959: [cmake] Fix for a bug https://llvm.org/bugs/show_bug.cgi?id=30489 "Cannot build with -DLIBOMP_FORTRAN_MODULES=True".
Sep 28 2016, 3:11 PM

Sep 27 2016

pawosm01 added a comment to D24959: [cmake] Fix for a bug https://llvm.org/bugs/show_bug.cgi?id=30489 "Cannot build with -DLIBOMP_FORTRAN_MODULES=True".

Tested, works.

Sep 27 2016, 4:14 PM
pawosm01 added a comment to D24959: [cmake] Fix for a bug https://llvm.org/bugs/show_bug.cgi?id=30489 "Cannot build with -DLIBOMP_FORTRAN_MODULES=True".

The way LIBOMP_OMPT_SUPPORT is handled brought me some idea though:

Sep 27 2016, 4:13 PM
pawosm01 added a comment to D24959: [cmake] Fix for a bug https://llvm.org/bugs/show_bug.cgi?id=30489 "Cannot build with -DLIBOMP_FORTRAN_MODULES=True".

Creating the directory during configuration time is not good. If someone deletes it from their build directory it will not be re-created until cmake is re-run. A better solution would be to create a separate add_custom_command that creates the directory, and a target that wraps that command. Then have the targets which have these POST_BUILD actions depend on the target that creates the directory.

Sep 27 2016, 3:59 PM
pawosm01 added a comment to D24959: [cmake] Fix for a bug https://llvm.org/bugs/show_bug.cgi?id=30489 "Cannot build with -DLIBOMP_FORTRAN_MODULES=True".

Also note that make_directory does not complain when created directory already exists (so parallel directory creation should not be a problem). If it was a problem, it would not be possible to re-run CMake after previous build and it would be noticed very quickly.

Sep 27 2016, 11:03 AM
pawosm01 added a comment to D24959: [cmake] Fix for a bug https://llvm.org/bugs/show_bug.cgi?id=30489 "Cannot build with -DLIBOMP_FORTRAN_MODULES=True".

I think this introduces a race during parallel builds where the POST_BUILD for the targets libomp-mod and omp both try to create the LIBOMP_EXPORTS_CMN_DIR.

To fix this, directories can be created during configuration time using file(MAKE_DIRECTORY ...). That way, all these lines can be removed:

COMMAND ${CMAKE_COMMAND} -E make_directory ...
Sep 27 2016, 10:55 AM
pawosm01 retitled D24959: [cmake] Fix for a bug https://llvm.org/bugs/show_bug.cgi?id=30489 "Cannot build with -DLIBOMP_FORTRAN_MODULES=True" from to [cmake] Fix for a bug https://llvm.org/bugs/show_bug.cgi?id=30489 "Cannot build with -DLIBOMP_FORTRAN_MODULES=True".
Sep 27 2016, 4:45 AM

Jul 29 2016

pawosm01 committed rL277212: Make balanced affinity work on AArch64..
Make balanced affinity work on AArch64.
Jul 29 2016, 2:02 PM
pawosm01 closed D22365: Make balanced affinity work on AArch64 (and possibly other architectures too) by committing rL277212: Make balanced affinity work on AArch64..
Jul 29 2016, 2:02 PM

Jul 25 2016

pawosm01 added a comment to D22365: Make balanced affinity work on AArch64 (and possibly other architectures too).

Actually, these are four helper functions, I didn't notice the smallest which only calls the other one.

Jul 25 2016, 3:11 AM