Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752811AbbKQJP6 (ORCPT ); Tue, 17 Nov 2015 04:15:58 -0500 Received: from smtprelay2.synopsys.com ([198.182.60.111]:34917 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752122AbbKQJPz convert rfc822-to-8bit (ORCPT ); Tue, 17 Nov 2015 04:15:55 -0500 From: Vineet Gupta To: Alexey Brodkin CC: Peter Zijlstra , arcml , lkml Subject: Re: local64_cmpxchg() in arc_perf_event_update() Thread-Topic: local64_cmpxchg() in arc_perf_event_update() Thread-Index: AQHRCq2wftAKd8gu/UufdgpljQdPow== Date: Tue, 17 Nov 2015 09:14:59 +0000 Message-ID: References: <1445286926.3913.13.camel@synopsys.com> Accept-Language: en-US, en-IN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.12.197.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1581 Lines: 38 On Tuesday 20 October 2015 02:05 AM, Alexey Brodkin wrote: > Hi Vineet, > > Looking at a patch that Peter Z mentioned: > http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/include/linux/perf_event.h?id=b0e878759452314676f > bdd71df4ac67e7d08de5d > > > And it says here http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/include/linux/perf_event.h#n160 > --------->8---------- > /* > * The last observed hardware counter value, updated with a > * local64_cmpxchg() such that pmu::read() can be called nested. > */ > local64_t prev_count; > --------->8---------- > > So now I think we may want to return to local64_cmpxchg() in arc_perf_event_update() as well. > The reason is having no control over generic perf code we cannot really guarantee that pmu->read() won't > happen at random moment right before we enter perf IRQ handler (where we execute arc_perf_event_update() directly). > > In other words arc_perf_event_update() is used in IRQ handler and outside it and chances are that > function will be reentered at some point. > > Agree? Let's check with Peter as I'm not sure how exactly the read call will nest for same counter on same core ? But if they do then indeed, then commit 1fe8bfa5ff3b (ARCv2: perf: implement "event_set_period") needs to be partially reverted. -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/