From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com. [185.58.86.151]) by gmr-mx.google.com with ESMTPS id c24si83006ljk.7.2020.12.11.06.19.10 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Dec 2020 06:19:10 -0800 (PST) From: David Laight Subject: RE: [patch 14/30] drm/i915/pmu: Replace open coded kstat_irqs() copy Date: Fri, 11 Dec 2020 14:19:05 +0000 Message-ID: References: <20201210192536.118432146@linutronix.de> <20201210194043.957046529@linutronix.de> <87y2i4h54i.fsf@nanos.tec.linutronix.de> In-Reply-To: <87y2i4h54i.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable To: 'Thomas Gleixner' , Tvrtko Ursulin , LKML Cc: Peter Zijlstra , Marc Zyngier , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , David Airlie , Daniel Vetter , "intel-gfx@lists.freedesktop.org" , "dri-devel@lists.freedesktop.org" , "James E.J. Bottomley" , Helge Deller , afzal mohammed , "linux-parisc@vger.kernel.org" , Russell King , "linux-arm-kernel@lists.infradead.org" , Mark Rutland , Catalin Marinas , Will Deacon , Christian Borntraeger , Heiko Carstens , "linux-s390@vger.kernel.org" , Pankaj Bharadiya , Chris Wilson , Wambui Karuga , Linus Walleij , "linux-gpio@vger.kernel.org" , Lee Jones , Jon Mason , Dave Jiang , Allen Hubbe , "linux-ntb@googlegroups.com" , Lorenzo Pieralisi , Rob Herring , Bjorn Helgaas , Michal Simek , "linux-pci@vger.kernel.org" , Karthikeyan Mitran , Hou Zhiqiang , Tariq Toukan , "David S. Miller" , Jakub Kicinski , "netdev@vger.kernel.org" , "linux-rdma@vger.kernel.org" , Saeed Mahameed , Leon Romanovsky , Boris Ostrovsky , Juergen Gross , Stefano Stabellini , "xen-devel@lists.xenproject.org" List-ID: From: Thomas Gleixner > Sent: 11 December 2020 12:58 .. > > After my failed hasty sketch from last night I had a different one whic= h > > was kind of heuristics based (re-reading the upper dword and retrying i= f > > it changed on 32-bit). >=20 > The problem is that there will be two seperate modifications for the low > and high word. Several ways how the compiler can translate this, but the > problem is the same for all of them: >=20 > CPU 0 CPU 1 > load low > load high > add low, 1 > addc high, 0 > store low load high > --> NMI load low > load high and compare > store high >=20 > You can't catch that. If this really becomes an issue you need a > sequence counter around it. Or just two copies of the high word. Provided the accesses are sequenced: writer: =09load high:low =09add small_value,high:low =09store high =09store low =09store high_copy reader: =09load high_copy =09load low =09load high =09if (high !=3D high_copy) =09=09low =3D 0; The read value is always stale, so it probably doesn't matter that the value you have is one that is between the value when you started and that when you finished. =09David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1= PT, UK Registration No: 1397386 (Wales) From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com. [185.58.86.151]) by gmr-mx.google.com with ESMTPS id c24si83006ljk.7.2020.12.11.06.19.10 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Dec 2020 06:19:10 -0800 (PST) From: David Laight Subject: RE: [patch 14/30] drm/i915/pmu: Replace open coded kstat_irqs() copy Date: Fri, 11 Dec 2020 14:19:05 +0000 Message-ID: References: <20201210192536.118432146@linutronix.de> <20201210194043.957046529@linutronix.de> <87y2i4h54i.fsf@nanos.tec.linutronix.de> In-Reply-To: <87y2i4h54i.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable To: 'Thomas Gleixner' , Tvrtko Ursulin , LKML Cc: Peter Zijlstra , Marc Zyngier , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , David Airlie , Daniel Vetter , "intel-gfx@lists.freedesktop.org" , "dri-devel@lists.freedesktop.org" , "James E.J. Bottomley" , Helge Deller , afzal mohammed , "linux-parisc@vger.kernel.org" , Russell King , "linux-arm-kernel@lists.infradead.org" , Mark Rutland , Catalin Marinas , Will Deacon , Christian Borntraeger , Heiko Carstens , "linux-s390@vger.kernel.org" , Pankaj Bharadiya , Chris Wilson , Wambui Karuga , Linus Walleij , "linux-gpio@vger.kernel.org" , Lee Jones , Jon Mason , Dave Jiang , Allen Hubbe , "linux-ntb@googlegroups.com" , Lorenzo Pieralisi , Rob Herring , Bjorn Helgaas , Michal Simek , "linux-pci@vger.kernel.org" , Karthikeyan Mitran , Hou Zhiqiang , Tariq Toukan , "David S. Miller" , Jakub Kicinski , "netdev@vger.kernel.org" , "linux-rdma@vger.kernel.org" , Saeed Mahameed , Leon Romanovsky , Boris Ostrovsky , Juergen Gross , Stefano Stabellini , "xen-devel@lists.xenproject.org" List-ID: From: Thomas Gleixner > Sent: 11 December 2020 12:58 .. > > After my failed hasty sketch from last night I had a different one whic= h > > was kind of heuristics based (re-reading the upper dword and retrying i= f > > it changed on 32-bit). >=20 > The problem is that there will be two seperate modifications for the low > and high word. Several ways how the compiler can translate this, but the > problem is the same for all of them: >=20 > CPU 0 CPU 1 > load low > load high > add low, 1 > addc high, 0 > store low load high > --> NMI load low > load high and compare > store high >=20 > You can't catch that. If this really becomes an issue you need a > sequence counter around it. Or just two copies of the high word. Provided the accesses are sequenced: writer: =09load high:low =09add small_value,high:low =09store high =09store low =09store high_copy reader: =09load high_copy =09load low =09load high =09if (high !=3D high_copy) =09=09low =3D 0; The read value is always stale, so it probably doesn't matter that the value you have is one that is between the value when you started and that when you finished. =09David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1= PT, UK Registration No: 1397386 (Wales) 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=-3.7 required=3.0 tests=BAYES_00, 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 04E99C1B0D9 for ; Mon, 14 Dec 2020 08:18:07 +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 A2897207A5 for ; Mon, 14 Dec 2020 08:18:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A2897207A5 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=ACULAB.COM Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 6CA016E090; Mon, 14 Dec 2020 08:17:42 +0000 (UTC) Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [185.58.86.151]) by gabe.freedesktop.org (Postfix) with ESMTPS id 0A67C6EE28 for ; Fri, 11 Dec 2020 14:19:14 +0000 (UTC) Received: from AcuMS.aculab.com (156.67.243.126 [156.67.243.126]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-53-s0AncPC_O7qxZEyLU7X13A-1; Fri, 11 Dec 2020 14:19:07 +0000 X-MC-Unique: s0AncPC_O7qxZEyLU7X13A-1 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) by AcuMS.aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 11 Dec 2020 14:19:05 +0000 Received: from AcuMS.Aculab.com ([fe80::43c:695e:880f:8750]) by AcuMS.aculab.com ([fe80::43c:695e:880f:8750%12]) with mapi id 15.00.1347.000; Fri, 11 Dec 2020 14:19:05 +0000 From: David Laight To: 'Thomas Gleixner' , Tvrtko Ursulin , LKML Subject: RE: [patch 14/30] drm/i915/pmu: Replace open coded kstat_irqs() copy Thread-Topic: [patch 14/30] drm/i915/pmu: Replace open coded kstat_irqs() copy Thread-Index: AQHWz72qwjNpP0n0UkWT70W8RrLS8qnx7xrw Date: Fri, 11 Dec 2020 14:19:05 +0000 Message-ID: References: <20201210192536.118432146@linutronix.de> <20201210194043.957046529@linutronix.de> <87y2i4h54i.fsf@nanos.tec.linutronix.de> In-Reply-To: <87y2i4h54i.fsf@nanos.tec.linutronix.de> Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C51A453 smtp.mailfrom=david.laight@aculab.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US X-Mailman-Approved-At: Mon, 14 Dec 2020 08:17:41 +0000 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Karthikeyan Mitran , Peter Zijlstra , Catalin Marinas , "dri-devel@lists.freedesktop.org" , Chris Wilson , "James E.J. Bottomley" , "netdev@vger.kernel.org" , Will Deacon , Michal Simek , "linux-s390@vger.kernel.org" , afzal mohammed , Lorenzo Pieralisi , Dave Jiang , "xen-devel@lists.xenproject.org" , Leon Romanovsky , "linux-rdma@vger.kernel.org" , Marc Zyngier , Helge Deller , Russell King , Christian Borntraeger , "linux-pci@vger.kernel.org" , Jakub Kicinski , Heiko Carstens , Wambui Karuga , Allen Hubbe , Juergen Gross , "intel-gfx@lists.freedesktop.org" , "linux-gpio@vger.kernel.org" , Stefano Stabellini , Rodrigo Vivi , Bjorn Helgaas , Lee Jones , "linux-arm-kernel@lists.infradead.org" , Boris Ostrovsky , David Airlie , "linux-parisc@vger.kernel.org" , Pankaj Bharadiya , Hou Zhiqiang , Tariq Toukan , Jon Mason , "linux-ntb@googlegroups.com" , Saeed Mahameed , "David S. Miller" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" From: Thomas Gleixner > Sent: 11 December 2020 12:58 .. > > After my failed hasty sketch from last night I had a different one which > > was kind of heuristics based (re-reading the upper dword and retrying if > > it changed on 32-bit). > > The problem is that there will be two seperate modifications for the low > and high word. Several ways how the compiler can translate this, but the > problem is the same for all of them: > > CPU 0 CPU 1 > load low > load high > add low, 1 > addc high, 0 > store low load high > --> NMI load low > load high and compare > store high > > You can't catch that. If this really becomes an issue you need a > sequence counter around it. Or just two copies of the high word. Provided the accesses are sequenced: writer: load high:low add small_value,high:low store high store low store high_copy reader: load high_copy load low load high if (high != high_copy) low = 0; The read value is always stale, so it probably doesn't matter that the value you have is one that is between the value when you started and that when you finished. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel 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=-3.7 required=3.0 tests=BAYES_00, 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 0376DC433FE for ; Fri, 11 Dec 2020 15:14:36 +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 90D6B207A4 for ; Fri, 11 Dec 2020 15:14:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 90D6B207A4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=ACULAB.COM 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 33F336E197; Fri, 11 Dec 2020 14:25:24 +0000 (UTC) X-Greylist: delayed 368 seconds by postgrey-1.36 at gabe; Fri, 11 Dec 2020 14:25:23 UTC Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [185.58.86.151]) by gabe.freedesktop.org (Postfix) with ESMTPS id 2BC836E197 for ; Fri, 11 Dec 2020 14:25:23 +0000 (UTC) Received: from AcuMS.aculab.com (156.67.243.126 [156.67.243.126]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-53-s0AncPC_O7qxZEyLU7X13A-1; Fri, 11 Dec 2020 14:19:07 +0000 X-MC-Unique: s0AncPC_O7qxZEyLU7X13A-1 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) by AcuMS.aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 11 Dec 2020 14:19:05 +0000 Received: from AcuMS.Aculab.com ([fe80::43c:695e:880f:8750]) by AcuMS.aculab.com ([fe80::43c:695e:880f:8750%12]) with mapi id 15.00.1347.000; Fri, 11 Dec 2020 14:19:05 +0000 From: David Laight To: 'Thomas Gleixner' , Tvrtko Ursulin , LKML Thread-Topic: [patch 14/30] drm/i915/pmu: Replace open coded kstat_irqs() copy Thread-Index: AQHWz72qwjNpP0n0UkWT70W8RrLS8qnx7xrw Date: Fri, 11 Dec 2020 14:19:05 +0000 Message-ID: References: <20201210192536.118432146@linutronix.de> <20201210194043.957046529@linutronix.de> <87y2i4h54i.fsf@nanos.tec.linutronix.de> In-Reply-To: <87y2i4h54i.fsf@nanos.tec.linutronix.de> Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C51A453 smtp.mailfrom=david.laight@aculab.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Subject: Re: [Intel-gfx] [patch 14/30] drm/i915/pmu: Replace open coded kstat_irqs() copy 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: , Cc: Mark Rutland , Karthikeyan Mitran , Peter Zijlstra , Catalin Marinas , Linus Walleij , "dri-devel@lists.freedesktop.org" , Chris Wilson , "James E.J. Bottomley" , "netdev@vger.kernel.org" , Will Deacon , Michal Simek , "linux-s390@vger.kernel.org" , afzal mohammed , Lorenzo Pieralisi , Dave Jiang , "xen-devel@lists.xenproject.org" , Leon Romanovsky , "linux-rdma@vger.kernel.org" , Marc Zyngier , Helge Deller , Russell King , Christian Borntraeger , "linux-pci@vger.kernel.org" , Jakub Kicinski , Heiko Carstens , Wambui Karuga , Allen Hubbe , Juergen Gross , Rob Herring , "intel-gfx@lists.freedesktop.org" , "linux-gpio@vger.kernel.org" , Stefano Stabellini , Bjorn Helgaas , Lee Jones , "linux-arm-kernel@lists.infradead.org" , Boris Ostrovsky , David Airlie , "linux-parisc@vger.kernel.org" , Hou Zhiqiang , Tariq Toukan , Jon Mason , "linux-ntb@googlegroups.com" , Saeed Mahameed , "David S. Miller" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" From: Thomas Gleixner > Sent: 11 December 2020 12:58 .. > > After my failed hasty sketch from last night I had a different one which > > was kind of heuristics based (re-reading the upper dword and retrying if > > it changed on 32-bit). > > The problem is that there will be two seperate modifications for the low > and high word. Several ways how the compiler can translate this, but the > problem is the same for all of them: > > CPU 0 CPU 1 > load low > load high > add low, 1 > addc high, 0 > store low load high > --> NMI load low > load high and compare > store high > > You can't catch that. If this really becomes an issue you need a > sequence counter around it. Or just two copies of the high word. Provided the accesses are sequenced: writer: load high:low add small_value,high:low store high store low store high_copy reader: load high_copy load low load high if (high != high_copy) low = 0; The read value is always stale, so it probably doesn't matter that the value you have is one that is between the value when you started and that when you finished. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx