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.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 C48D6C4743F for ; Sat, 12 Dec 2020 01:01:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A61DB2343E for ; Sat, 12 Dec 2020 01:01:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2406179AbgLKOU5 convert rfc822-to-8bit (ORCPT ); Fri, 11 Dec 2020 09:20:57 -0500 Received: from eu-smtp-delivery-151.mimecast.com ([185.58.86.151]:26649 "EHLO eu-smtp-delivery-151.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2406027AbgLKOUr (ORCPT ); Fri, 11 Dec 2020 09:20:47 -0500 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 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" 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org 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)