public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/99555] [OpenMP/nvptx] Execution-time hang for simple nested OpenMP 'target'/'parallel'/'task' constructs
Date: Tue, 22 Feb 2022 14:53:02 +0000	[thread overview]
Message-ID: <bug-99555-4-IHS4iikZTk@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-99555-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99555

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <vries@gcc.gnu.org>:

https://gcc.gnu.org/g:5ed77fb3ed1ee0289a0ec9499ef52b99b39421f1

commit r12-7332-g5ed77fb3ed1ee0289a0ec9499ef52b99b39421f1
Author: Tom de Vries <tdevries@suse.de>
Date:   Tue Apr 20 08:47:03 2021 +0200

    [libgomp, nvptx] Fix hang in gomp_team_barrier_wait_end

    Consider the following omp fragment.
    ...
      #pragma omp target
      #pragma omp parallel num_threads (2)
      #pragma omp task
        ;
    ...

    This hangs at -O0 for nvptx.

    Investigating the behaviour gives us the following trace of events:
    - both threads execute GOMP_task, where they:
      - deposit a task, and
      - execute gomp_team_barrier_wake
    - thread 1 executes gomp_team_barrier_wait_end and, not being the last
thread,
      proceeds to wait at the team barrier
    - thread 0 executes gomp_team_barrier_wait_end and, being the last thread,
it
      calls gomp_barrier_handle_tasks, where it:
      - executes both tasks and marks the team barrier done
      - executes a gomp_team_barrier_wake which wakes up thread 1
    - thread 1 exits the team barrier
    - thread 0 returns from gomp_barrier_handle_tasks and goes to wait at
      the team barrier.
    - thread 0 hangs.

    To understand why there is a hang here, it's good to understand how things
    are setup for nvptx.  The libgomp/config/nvptx/bar.c implementation is
    a copy of the libgomp/config/linux/bar.c implementation, with uses of both
    futex_wake and do_wait replaced with uses of ptx insn bar.sync:
    ...
      if (bar->total > 1)
        asm ("bar.sync 1, %0;" : : "r" (32 * bar->total));
    ...

    The point where thread 0 goes to wait at the team barrier, corresponds in
    the linux implementation with a do_wait.  In the linux case, the call to
    do_wait doesn't hang, because it's waiting for bar->generation to become
    a certain value, and if bar->generation already has that value, it just
    proceeds, without any need for coordination with other threads.

    In the nvtpx case, the bar.sync waits until thread 1 joins it in the same
    logical barrier, which never happens: thread 1 is lingering in the
    thread pool at the thread pool barrier (using a different logical barrier),
    waiting to join a new team.

    The easiest way to fix this is to revert to the posix implementation for
    bar.{c,h}.  That however falls back on a busy-waiting approach, and
    does not take advantage of the ptx bar.sync insn.

    Instead, we revert to the linux implementation for bar.c,
    and implement bar.c local functions futex_wait and futex_wake using the
    bar.sync insn.

    The bar.sync insn takes an argument specifying how many threads are
    participating, and that doesn't play well with the futex syntax where it's
    not clear in advance how many threads will be woken up.

    This is solved by waking up all waiting threads each time a futex_wait or
    futex_wake happens, and possibly going back to sleep with an updated thread
    count.

    Tested libgomp on x86_64 with nvptx accelerator.

    libgomp/ChangeLog:

    2021-04-20  Tom de Vries  <tdevries@suse.de>

            PR target/99555
            * config/nvptx/bar.c (generation_to_barrier): New function, copied
            from config/rtems/bar.c.
            (futex_wait, futex_wake): New function.
            (do_spin, do_wait): New function, copied from config/linux/wait.h.
            (gomp_barrier_wait_end, gomp_barrier_wait_last)
            (gomp_team_barrier_wake, gomp_team_barrier_wait_end):
            (gomp_team_barrier_wait_cancel_end, gomp_team_barrier_cancel):
Remove
            and replace with include of config/linux/bar.c.
            * config/nvptx/bar.h (gomp_barrier_t): Add fields waiters and lock.
            (gomp_barrier_init): Init new fields.
            * testsuite/libgomp.c-c++-common/task-detach-6.c: Remove
nvptx-specific
            workarounds.
            * testsuite/libgomp.c/pr99555-1.c: Same.
            * testsuite/libgomp.fortran/task-detach-6.f90: Same.

  parent reply	other threads:[~2022-02-22 14:53 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-11 16:36 [Bug target/99555] New: " tschwinge at gcc dot gnu.org
2021-03-12 15:53 ` [Bug target/99555] " vries at gcc dot gnu.org
2021-03-25 12:00 ` cvs-commit at gcc dot gnu.org
2021-03-29  8:41 ` cvs-commit at gcc dot gnu.org
2021-04-15  8:02 ` vries at gcc dot gnu.org
2021-04-15  9:14 ` cvs-commit at gcc dot gnu.org
2021-04-17  8:07 ` vries at gcc dot gnu.org
2021-04-19 10:44 ` vries at gcc dot gnu.org
2021-04-19 11:15 ` vries at gcc dot gnu.org
2021-04-19 15:39 ` vries at gcc dot gnu.org
2021-04-20 11:24 ` vries at gcc dot gnu.org
2022-02-22 14:53 ` cvs-commit at gcc dot gnu.org [this message]
2022-02-22 14:54 ` vries at gcc dot gnu.org
2022-03-17 12:16 ` tschwinge at gcc dot gnu.org
2022-05-13 13:16 ` tschwinge at gcc dot gnu.org
2022-09-06 13:32 ` vries at gcc dot gnu.org
2022-12-21 13:59 ` cvs-commit at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-99555-4-IHS4iikZTk@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).