All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Mika Kuoppala <mika.kuoppala@linux.intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/2] drm/i915: Add compiler barrier to wait_for
Date: Fri, 20 Apr 2018 14:52:54 +0100	[thread overview]
Message-ID: <152423237459.6471.5537062750050308894@mail.alporthouse.com> (raw)
In-Reply-To: <20180420134550.17590-2-mika.kuoppala@linux.intel.com>

Quoting Mika Kuoppala (2018-04-20 14:45:50)
> We need to be careful to not let compiler evaluate
> the expiration and the operation on it's terms.
> 
> Document and enforce that COND will be evaluated
> before checking timeout expiration.
> 
> Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> ---
>  drivers/gpu/drm/i915/intel_drv.h | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> index ac7565220aa3..4dc346716bb4 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -56,6 +56,8 @@
>         for (;;) {                                                      \
>                 const bool expired__ = ktime_after(ktime_get_raw(), end__); \
>                 OP;                                                     \
> +               /* Guarantee COND check prior to timeout */             \
> +               barrier();                                              \

Which side of OP is debatable, since OP is caller supplied and our
constraint is targeted at expired__. However, it is likely to be more
useful between OP/COND, so I can see some advantage there.

As Mika noted, moving to a function call should mean that the compiler
has less freedom to reorder/re-evaluate but doesn't completely prevent
it. As such being clear about the order of operations here is just as
important for the reader. There is a long history of gotchas here, and
this patch set continues the trend :)

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-04-20 13:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-20 13:45 [PATCH 1/2] drm/i915: Use ktime on wait_for Mika Kuoppala
2018-04-20 13:45 ` [PATCH 2/2] drm/i915: Add compiler barrier to wait_for Mika Kuoppala
2018-04-20 13:52   ` Chris Wilson [this message]
2018-04-20 16:10 ` ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Use ktime on wait_for Patchwork
2018-04-20 16:55 ` ✗ Fi.CI.IGT: failure " Patchwork
2018-04-24 12:22   ` Martin Peres
2018-04-24 12:45     ` Mika Kuoppala

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=152423237459.6471.5537062750050308894@mail.alporthouse.com \
    --to=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=mika.kuoppala@linux.intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.