intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Michel Thierry <michel.thierry@intel.com>,
	Mika Kuoppala <mika.kuoppala@linux.intel.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: [PATCH] drm/i915/execlists: Use a locked clear_bit() for synchronisation with interrupt
Date: Thu, 22 Mar 2018 12:04:32 +0200	[thread overview]
Message-ID: <87lgekifyn.fsf@intel.com> (raw)
In-Reply-To: <152171139291.23562.11975591019595867325@mail.alporthouse.com>

On Thu, 22 Mar 2018, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> Quoting Jani Nikula (2018-03-22 09:34:18)
>> On Wed, 21 Mar 2018, Chris Wilson <chris@chris-wilson.co.uk> wrote:
>> > Quoting Michel Thierry (2018-03-21 17:01:12)
>> >> On 3/21/2018 3:46 AM, Mika Kuoppala wrote:
>> >> > Chris Wilson <chris@chris-wilson.co.uk> writes:
>> >> >> -            /* The write will be ordered by the uncached read (itself
>> >> >> -             * a memory barrier), so we do not need another in the form
>> >> >> -             * of a locked instruction. The race between the interrupt
>> >> >> -             * handler and the split test/clear is harmless as we order
>> >> >> -             * our clear before the CSB read. If the interrupt arrived
>> >> >> -             * first between the test and the clear, we read the updated
>> >> >> -             * CSB and clear the bit. If the interrupt arrives as we read
>> >> >> -             * the CSB or later (i.e. after we had cleared the bit) the bit
>> >> >> -             * is set and we do a new loop.
>> >> >> -             */
>> >> >> -            __clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
>> >> >> +            /* Clear before reading to catch new interrupts */
>> >> >> +            clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
>> >> >> +            smp_mb__after_atomic();
>> >> 
>> >> Checkpatch wants a comment for the memory barrier... Are we being strict 
>> >> about it? (https://patchwork.freedesktop.org/series/40359/)
>> >
>> > There's a comment for it not two lines above! Silly perl script.
>> 
>> Sure, it's nowhere near perfect. But I do like to get the reminder about
>> this, "hey don't forget to document your memory barriers, locks,
>> etc.". It does mean we can't use checkpatch for gating, but I think it
>> can make the reviewer's life easier to be able to just point at the
>> results, and ask the author to fix the relevant stuff. I think it's less
>> tedious and less offensive than the reviewer doing the job manually.
>
> The complaint was only in jest. The reminder to document locks and mb is
> indeed invaluable, just sometimes the limitation of being a "dumb" perl
> script show through.

Oh, I didn't misread you. I just switched to serious mode because we do
need to evaluate whether the checkpatch reports from CI are net positive
or negative, and, either way, what can we do to further improve the S/N.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-03-22 10:03 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-21  9:10 [PATCH] drm/i915/execlists: Use a locked clear_bit() for synchronisation with interrupt Chris Wilson
2018-03-21  9:19 ` ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2018-03-21  9:35 ` ✗ Fi.CI.BAT: " Patchwork
2018-03-21 10:14 ` [PATCH] " Tvrtko Ursulin
2018-03-21 10:24 ` ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2018-03-21 10:42 ` ✗ Fi.CI.BAT: failure " Patchwork
2018-03-21 10:46 ` [PATCH] " Mika Kuoppala
2018-03-21 17:01   ` Michel Thierry
2018-03-21 17:05     ` Chris Wilson
2018-03-21 17:07       ` Chris Wilson
2018-03-22  9:34       ` Jani Nikula
2018-03-22  9:36         ` Chris Wilson
2018-03-22 10:04           ` Jani Nikula [this message]
2018-03-21 17:10     ` Chris Wilson
2018-03-21 11:31 ` ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2018-03-21 11:51 ` ✓ Fi.CI.BAT: success " Patchwork
2018-03-21 13:40 ` ✓ Fi.CI.IGT: " Patchwork

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=87lgekifyn.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=michel.thierry@intel.com \
    --cc=mika.kuoppala@linux.intel.com \
    --cc=rodrigo.vivi@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 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 NNTP newsgroup(s).