Red Hat Bugzilla – Bug 463320
[LTC 6.0 FEAT] 201443:Support barrier synchronization facility in POWER5 and POWER6 CPUs
Last modified: 2010-10-18 10:26:45 EDT
Emily J. Ratliff <firstname.lastname@example.org> - 2008-09-16 18:28 EDT
1. Feature Overview:
Feature Id: 
a. Name of Feature: Support barrier synchronization facility in POWER5 and POWER6 CPUs
b. Feature Description
Kernel and library support for making the POWER5/6 barrier synchronization (BSR) facility available
to applications. The BSR facility provides low-latency barrier synchronization, which is useful for
HPC and other multi-threaded applications that wish to wait until all threads have reached a certain
point in the program. The kernel support will be a device driver for a /dev/bsr device (or
/dev/misc/bsr) which supports mmap and ioctl calls. The ioctl call will be used to allocate a
section of the BSR facility, and mmap will be used to map the allocated BSR registers into
userspace. A userspace library will provide an API similar to that provided by the AIX bsr_alloc,
bsr_query and bsr_free calls.
2. Feature Details:
Arch Specificity: Purely Arch Specific Code
Affects Core Kernel: Yes
Delivery Mechanism: Direct from community
Request Type: Kernel - Enhancement from IBM
d. Upstream Acceptance: Accepted
Sponsor Priority 1
f. Severity: High
IBM Confidential: no
Code Contribution: IBM code
g. Component Version Target: 2.6.27
3. Business Case
HPC improvement. This will be needed for parallel-processing applications so that the application
uses a BSR to perform barrier synchronization, which is a method for synchronizing the threads in
the parallel-processing application.
4. Primary contact at Red Hat:
5. Primary contacts at Partner:
Project Management Contact:
Michael Hohnbaum, email@example.com, 503-578-5486
Paul Mackerras, firstname.lastname@example.org
Pat Gaughen, email@example.com
Is there a reason this isn't done via libc support in pthread_barrier_*?
pthread_barrier_* could use BSR, but with some major restrictions.
There is only one BSR per system and it has a limited size,
so it'd have to fall back on a normal implementation if
more than N threads used it (very tricky to detect that ahead of time
BSR is really too restrictive to be used in a general barrier
implementation like in the pthreads library.
Wouldn't this mean that the userspace library (or the app that called it) would have to do the exact same tests?
Yes, the library would have to acquire exclusive access to some or all of the BSR and fall back to a conventional barrier if it weren't available. We're planning on using libbsr to handle exclusion for user's who want to access the BSR. The expectation though it that on HPC machines there would be a single -- or at most a few apps -- which run at the same time, and there would not be heavy contention on the BSR in that environment.
this is in 2.6.27
sha1 id: fe9e8d53772b5ea9ccf8ea4e8f0f009a6885eb70
OK, marking as MODIFIED.
The feature requested has already been accepted into the upstream code base
planned for the next major release of Red Hat Enterprise Linux.
When the next milestone release of Red Hat Enterprise Linux 6 is available,
please verify that the feature requested is present and functioning as
Closing as support is available in current release.