From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754241AbcAMA4G (ORCPT ); Tue, 12 Jan 2016 19:56:06 -0500 Received: from mail.fireflyinternet.com ([87.106.93.118]:64472 "EHLO fireflyinternet.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753223AbcAMA4F (ORCPT ); Tue, 12 Jan 2016 19:56:05 -0500 X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=78.156.65.138; Date: Wed, 13 Jan 2016 00:55:21 +0000 From: Chris Wilson To: Linus Torvalds Cc: Andy Lutomirski , "H. Peter Anvin" , "linux-kernel@vger.kernel.org" , Ross Zwisler , "H . Peter Anvin" , Borislav Petkov , Brian Gerst , Denys Vlasenko , Thomas Gleixner , Imre Deak , Daniel Vetter , DRI Subject: Re: [PATCH] x86: Add an explicit barrier() to clflushopt() Message-ID: <20160113005521.GD25945@nuc-i3427.alporthouse.com> Mail-Followup-To: Chris Wilson , Linus Torvalds , Andy Lutomirski , "H. Peter Anvin" , "linux-kernel@vger.kernel.org" , Ross Zwisler , "H . Peter Anvin" , Borislav Petkov , Brian Gerst , Denys Vlasenko , Thomas Gleixner , Imre Deak , Daniel Vetter , DRI References: <568EE777.80700@zytor.com> <20160109080138.GG652@nuc-i3427.alporthouse.com> <20160111112801.GR652@nuc-i3427.alporthouse.com> <20160111210506.GO652@nuc-i3427.alporthouse.com> <20160112163757.GG24672@nuc-i3427.alporthouse.com> <20160112211357.GM24672@nuc-i3427.alporthouse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 12, 2016 at 02:07:35PM -0800, Linus Torvalds wrote: > On Tue, Jan 12, 2016 at 1:13 PM, Chris Wilson wrote: > > Indeed. So I replaced the post-clflush_cache_range() clflush() with a > > udelay(10) instead, and the corruption vanished. Putting the udelay(10) > > before the clflush_cache_range() does not fix the corruption. > > Odd. > > > passes, I'm inclined to point the finger at the mb() following the > > clflush_cache_range(). > > We have an entirely unrelated discussion about the value of "mfence" > as a memory barrier. > > Mind trying to just make the memory barrier (in > arch/x86/include/asm/barrier.h) be a locked op instead? Replacing the following mb() in clflush_cache_range() with "lock; addl $0,0(%%rsp)" gave no improvement. Neither did replacing all mb(). Undoubtably the memory stream as seen by the CPU is serialised. The concern then is back to the visibility of the stream from the external device. Adding an uncached mmio read after the clflush_cache_range() also works, but I'm not clear if this achieves anything other than inserting a delay or if it is flushing some other write buffer in the chipset. It is odd that is required after the clflush_cache_range() and ineffective before. It is also odd that such a flush would be needed multiple times after the GPU write. The double clflush() remains a mystery. -Chris -- Chris Wilson, Intel Open Source Technology Centre