public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Martin Jambor <mjambor@suse.cz>
To: Jakub Jelinek <jakub@redhat.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [hsa 2/10] Modifications to libgomp proper
Date: Tue, 12 Jan 2016 13:46:00 -0000	[thread overview]
Message-ID: <20160112134652.GN3060@virgil.suse.cz> (raw)
In-Reply-To: <20151211180529.GH5675@tucnak.redhat.com>

Hi,

On Fri, Dec 11, 2015 at 07:05:29PM +0100, Jakub Jelinek wrote:
> On Thu, Dec 10, 2015 at 06:52:23PM +0100, Martin Jambor wrote:
> > > > --- a/libgomp/task.c
> > > > +++ b/libgomp/task.c
> > > > @@ -581,6 +581,7 @@ GOMP_PLUGIN_target_task_completion (void *data)
> > > >        gomp_mutex_unlock (&team->task_lock);
> > > >      }
> > > >    ttask->state = GOMP_TARGET_TASK_FINISHED;
> > > > +  free (ttask->firstprivate_copies);
> > > >    gomp_target_task_completion (team, task);
> > > >    gomp_mutex_unlock (&team->task_lock);
> > > >  }
> > > 
> > > So, this function should have a special case for the SHARED_MEM case, handle
> > > it closely to say how GOMP_taskgroup_end handles the finish_cancelled:
> > > case.  Just note that the target task is missing from certain queues at that
> > > point.
> > 
> > I'm afraid I need some help here.  I do not quite understand how is
> > finish_cancelled in GOMP_taskgroup_end similar, it seems to be doing
> > much more than freeing one pointer.  What is exactly the issue with
> > the above?
> > 
> > Nevertheless, after reading through bits of task.c again, I wonder
> > whether any copying (for both shared memory target and the host) in
> > gomp_target_task_fn is actually necessary because it seems to be also
> > done in gomp_create_target_task.  Does that not apply somehow?
> 
> The target task is scheduled for the first action as normal task, and the
> scheduling of it already removes it from some of the queues (each task is
> put into 1-3 queues), i.e. actions performed mostly by
> gomp_task_run_pre.  Then the team task lock is unlocked and the task is run.
> Finally, for normal tasks, gomp_task_run_post_handle_depend,
> gomp_task_run_post_remove_parent, etc. is run.  Now, for async target tasks
> that have something running on some other device at that point, we don't do
> that, but instead make it GOMP_TASK_ASYNC_RUNNING.  And continue with other
> stuff, until gomp_target_task_completion is run.
> For non-shared mem that needs to readd the task again into the queues, so
> that it will be scheduled again.  But you don't need that for shared mem
> target tasks, they can just free the firstprivate_copies and finalize the
> task.
> At the time gomp_target_task_completion is called, the task is pretty much
> in the same state as it is around the finish_cancelled:; label.
> So instead of what the gomp_target_task_completion function does,
> you would for SHARED_MEM do something like:
>           size_t new_tasks
>             = gomp_task_run_post_handle_depend (task, team);
>           gomp_task_run_post_remove_parent (task);
>           gomp_clear_parent (&task->children_queue);
>           gomp_task_run_post_remove_taskgroup (task);
>           team->task_count--;
> 	  do_wake = 0;
>           if (new_tasks > 1)
>             {
>               do_wake = team->nthreads - team->task_running_count
>                         - !task->in_tied_task;
>               if (do_wake > new_tasks)
>                 do_wake = new_tasks;
>             }
> // Unlike other places, the following will be also run with the
> // task_lock held, but I'm afraid there is nothing to do about it.
> // See the comment in gomp_target_task_completion.
> 	  gomp_finish_task (task);
> 	  free (task);
> 	  if (do_wake)
> 	    gomp_team_barrier_wake (&team->barrier, do_wake);
> 

I tried the above but libgomp testcase target-33.c always got stuck
within GOMP_taskgroup_end call, more specifically in
gomp_team_barrier_wait_end in config/linux/bar.c where the the first
call to gomp_barrier_handle_tasks left the barrier->generation as
BAR_WAITING_FOR_TASK and then nothing ever happened, even as the
callbacks fired.

After looking into the tasking mechanism for basically the whole day
yesterday, I *think* I fixed it by calling
gomp_team_barrier_set_task_pending from the callback and another hunk
in gomp_barrier_handle_tasks so that it clears that barrier flag even
if it has not picked up any tasks.  Please let me know if you think it
makes sense.

If so, I'll include it in an HSA patch set I hope to generate today.
Otherwise I guess I'd prefer to remove the shared-memory path and
revert to old behavior as a temporary measure until we find out what
was wrong.

Thanks and sorry that it took me so long to resolve this,

Martin


diff --git a/libgomp/task.c b/libgomp/task.c
index ab5df51..828c1fb 100644
--- a/libgomp/task.c
+++ b/libgomp/task.c
@@ -566,6 +566,14 @@ gomp_target_task_completion (struct gomp_team *team, struct gomp_task *task)
     gomp_team_barrier_wake (&team->barrier, 1);
 }
 
+static inline size_t
+gomp_task_run_post_handle_depend (struct gomp_task *child_task,
+				  struct gomp_team *team);
+static inline void
+gomp_task_run_post_remove_parent (struct gomp_task *child_task);
+static inline void
+gomp_task_run_post_remove_taskgroup (struct gomp_task *child_task);
+
 /* Signal that a target task TTASK has completed the asynchronously
    running phase and should be requeued as a task to handle the
    variable unmapping.  */
@@ -584,8 +592,34 @@ GOMP_PLUGIN_target_task_completion (void *data)
       gomp_mutex_unlock (&team->task_lock);
     }
   ttask->state = GOMP_TARGET_TASK_FINISHED;
-  free (ttask->firstprivate_copies);
-  gomp_target_task_completion (team, task);
+
+  if (ttask->devicep->capabilities & GOMP_OFFLOAD_CAP_SHARED_MEM)
+    {
+      free (ttask->firstprivate_copies);
+      size_t new_tasks
+	= gomp_task_run_post_handle_depend (task, team);
+      gomp_task_run_post_remove_parent (task);
+      gomp_clear_parent (&task->children_queue);
+      gomp_task_run_post_remove_taskgroup (task);
+      team->task_count--;
+      int do_wake = 0;
+      if (new_tasks)
+	{
+	  do_wake = team->nthreads - team->task_running_count
+	    - !task->in_tied_task;
+	  if (do_wake > new_tasks)
+	    do_wake = new_tasks;
+	}
+      /* Unlike other places, the following will be also run with the task_lock
+         held, but there is nothing to do about it.  See the comment in
+         gomp_target_task_completion.  */
+      gomp_finish_task (task);
+      free (task);
+      gomp_team_barrier_set_task_pending (&team->barrier);
+      gomp_team_barrier_wake (&team->barrier, do_wake ? do_wake : 1);
+    }
+  else
+    gomp_target_task_completion (team, task);
   gomp_mutex_unlock (&team->task_lock);
 }
 
@@ -1275,7 +1309,12 @@ gomp_barrier_handle_tasks (gomp_barrier_state_t state)
 	  thr->task = task;
 	}
       else
-	return;
+	{
+	  if (team->task_count == 0
+	      && gomp_team_barrier_waiting_for_tasks (&team->barrier))
+	    gomp_team_barrier_done (&team->barrier, state);
+	  return;
+	}
       gomp_mutex_lock (&team->task_lock);
       if (child_task)
 	{

  reply	other threads:[~2016-01-12 13:46 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-07 11:18 [hsa 0/10] Merge of HSA branch Martin Jambor
2015-12-07 11:19 ` [hsa 1/10] Configury changes and new options Martin Jambor
2015-12-08 22:43   ` Richard Sandiford
2015-12-10 17:52     ` Martin Jambor
2015-12-11 17:42       ` Jakub Jelinek
2015-12-10 17:52   ` Martin Jambor
2015-12-07 11:20 ` [hsa 3/10] HSA libgomp plugin Martin Jambor
2015-12-09 12:16   ` Jakub Jelinek
2015-12-10 12:06     ` [hsa 3/10] HSA libgomp plugin [part 2/2] Martin Liška
2015-12-10 12:06     ` [hsa 3/10] HSA libgomp plugin [part 1/2] Martin Liška
2015-12-07 11:20 ` [hsa 2/10] Modifications to libgomp proper Martin Jambor
2015-12-09 11:55   ` Jakub Jelinek
2015-12-10 17:52     ` Martin Jambor
2015-12-11 18:05       ` Jakub Jelinek
2016-01-12 13:46         ` Martin Jambor [this message]
2016-01-12 14:23           ` Jakub Jelinek
2016-01-15 20:00             ` Jakub Jelinek
2016-01-12 13:00   ` Alexander Monakov
2016-01-12 13:10     ` Jakub Jelinek
     [not found]       ` <20160112132905.GM3060@virgil.suse.cz>
2016-01-12 13:38         ` Jakub Jelinek
2016-01-12 18:51           ` Martin Jambor
2015-12-07 11:21 ` [hsa 4/10] Merge of HSA branch Martin Jambor
2015-12-09 12:17   ` Jakub Jelinek
2015-12-07 11:23 ` [hsa 5/10] OpenMP lowering/expansion changes (gridification) Martin Jambor
2015-12-09 13:19   ` Jakub Jelinek
2015-12-09 16:25     ` Splitting up gcc/omp-low.c? (was: [hsa 5/10] OpenMP lowering/expansion changes (gridification)) Thomas Schwinge
2015-12-09 17:23       ` Splitting up gcc/omp-low.c? Bernd Schmidt
2015-12-10  8:08         ` Jakub Jelinek
2015-12-10 11:26           ` Bernd Schmidt
2015-12-10 11:34             ` Jakub Jelinek
2015-12-15 18:28               ` Nathan Sidwell
2016-04-08  9:36           ` Thomas Schwinge
2016-04-08 10:46             ` Martin Jambor
2016-04-08 11:08             ` Jakub Jelinek
2016-04-13 16:01             ` Thomas Schwinge
2016-04-13 17:38               ` Bernd Schmidt
2016-04-13 17:56                 ` Thomas Schwinge
2016-04-13 18:20                   ` Bernd Schmidt
2016-04-14 13:36                     ` Thomas Schwinge
2016-04-14 16:01                       ` Bernd Schmidt
2016-04-14 16:01               ` Thomas Schwinge
2016-04-14 20:28                 ` Split out OMP constructs' SIMD clone supporting code (was: Splitting up gcc/omp-low.c?) Thomas Schwinge
2016-04-15  6:25                   ` Split out OMP constructs' SIMD clone supporting code Thomas Schwinge
2016-04-15 11:15                   ` Split out OMP constructs' SIMD clone supporting code (was: Splitting up gcc/omp-low.c?) Jakub Jelinek
2016-04-15 11:53                     ` Thomas Schwinge
2016-04-15 11:57                       ` Jakub Jelinek
2016-04-15 12:11                         ` Thomas Schwinge
2016-04-15 12:15                           ` Jakub Jelinek
2016-04-15 14:33                             ` Thomas Schwinge
2016-05-03  9:34               ` Splitting up gcc/omp-low.c? Thomas Schwinge
2016-05-11 13:44                 ` Thomas Schwinge
2016-05-18 11:42                   ` Thomas Schwinge
2016-05-25  9:17                     ` Thomas Schwinge
2016-05-25 12:54                       ` Martin Jambor
2015-12-18 14:29     ` [hsa 5/10] OpenMP lowering/expansion changes (gridification) Martin Jambor
2015-12-07 11:24 ` [hsa 6/10] Pass manager changes Martin Jambor
2015-12-09 13:20   ` Jakub Jelinek
2015-12-09 13:47     ` Richard Biener
2015-12-07 11:25 ` [hsa 7/10] IPA-HSA pass Martin Jambor
2015-12-07 11:27 ` [hsa 8/10] HSAIL BRIG description header file (and a steering committee request) Martin Jambor
2015-12-07 11:29 ` [hsa 9/10] Majority of the HSA back-end Martin Jambor
2015-12-07 11:30 ` [hsa 10/10] HSA register allocator Martin Jambor
2015-12-07 11:46 ` [hsa 0/10] Merge of HSA branch Jakub Jelinek
2015-12-10 17:51   ` Martin Jambor
2016-01-26 10:46     ` (Non-)offloading diagnostics (was: [hsa 0/10] Merge of HSA branch) Thomas Schwinge
2016-01-26 11:18       ` Alexander Monakov
2016-01-26 11:38         ` (Non-)offloading diagnostics Thomas Schwinge
2016-02-26 16:46       ` Thomas Schwinge
2016-02-26 17:18         ` Martin Jambor
2016-02-26 17:51           ` Jakub Jelinek
2016-02-26 18:48             ` Martin Jambor

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=20160112134652.GN3060@virgil.suse.cz \
    --to=mjambor@suse.cz \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    /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).