From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8EE75C352A3 for ; Tue, 11 Feb 2020 16:00:28 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6F8E020714 for ; Tue, 11 Feb 2020 16:00:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6F8E020714 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=chris-wilson.co.uk Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 8CF256E500; Tue, 11 Feb 2020 16:00:27 +0000 (UTC) Received: from fireflyinternet.com (unknown [77.68.26.236]) by gabe.freedesktop.org (Postfix) with ESMTPS id 860ED6E500 for ; Tue, 11 Feb 2020 16:00:25 +0000 (UTC) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=78.156.65.138; Received: from localhost (unverified [78.156.65.138]) by fireflyinternet.com (Firefly Internet (M1)) with ESMTP (TLS) id 20189263-1500050 for multiple; Tue, 11 Feb 2020 16:00:09 +0000 MIME-Version: 1.0 To: Mika Kuoppala , intel-gfx@lists.freedesktop.org From: Chris Wilson In-Reply-To: <877e0t9l28.fsf@gaia.fi.intel.com> References: <20200210205722.794180-1-chris@chris-wilson.co.uk> <20200210205722.794180-3-chris@chris-wilson.co.uk> <87a75p9mhf.fsf@gaia.fi.intel.com> <158143518042.3635.5696176952305833936@skylake-alporthouse-com> <877e0t9l28.fsf@gaia.fi.intel.com> Message-ID: <158143680805.3635.3897704980251056837@skylake-alporthouse-com> User-Agent: alot/0.6 Date: Tue, 11 Feb 2020 16:00:08 +0000 Subject: Re: [Intel-gfx] [PATCH 3/7] drm/i915/selftests: Relax timeout for error-interrupt reset processing X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" Quoting Mika Kuoppala (2020-02-11 15:54:07) > Chris Wilson writes: > > > Quoting Mika Kuoppala (2020-02-11 15:23:24) > >> Chris Wilson writes: > >> > + /* Kick the tasklet to process the error */ > >> > + intel_engine_flush_submission(engine); > >> > >> This pattern of usage in selftests makes me want to add mb(); to > >> intel_engine_flush_submission(), as it does not seem to do it > >> implicitly. > >> > >> We want to flush submission and observe the effects, thus > >> it seems like a good place. > > > > Hmm. From the cpu perspective the memory barrier would be on the other > > side in clear_bit_unlock(), and flush_submission does unlock_wait. > > > > But, then, we have to factor in that we have to communicate with an > > external client the GPU, so perhaps an explicit memory barrier... > > > > We certainly do perform the memory barrier in order to set the GPU in > > motion, but have not relied on them for observing effects (aside from > > the CSB ringbuf). > > > > I don't see a strong argument that adding a 'mb/rmb' here will make any > > difference, I don't see what we are pairing with from the GPU > > perspective. But maybe there is? > > I don't have a strong argument from gpu side. But what if the > flush only does the nonatomic wait and returns, and our > CPU has read the state up front for the next comparison. > > Or now thinking it, the saving grace is that if we don't need > to flush in here, the tasklet has finished and finish has > the barrier? That's how we synchronize with the tasklet, yes. So by this point (as we expect to have a request ready and scheduled the tasklet) we know that the tasklet has completed. So we know we've *initiated* some action on the GPU. Most of the side-effects from doing so are without barriers. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx