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=-4.0 required=3.0 tests=BAYES_00,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 6EFADC2D0E4 for ; Fri, 20 Nov 2020 20:04:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1260A2240A for ; Fri, 20 Nov 2020 20:04:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730302AbgKTUDt (ORCPT ); Fri, 20 Nov 2020 15:03:49 -0500 Received: from mail-ot1-f67.google.com ([209.85.210.67]:35718 "EHLO mail-ot1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729484AbgKTUDs (ORCPT ); Fri, 20 Nov 2020 15:03:48 -0500 Received: by mail-ot1-f67.google.com with SMTP id n11so9886671ota.2 for ; Fri, 20 Nov 2020 12:03:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=kOieT1B4Wy217FTmYdr9SeWcw+wzIYUCF7lyPYhxoIQ=; b=aAEsxJdSV5on6is+QjK81iAmVgLAWGslmjrOqD1Hg2hbGk3vhCXbz4YdueCQxH/rEP 2bnqOPmFFXHwioq48cEO87/lKcjcOy5EoCxoZk7v7YbeDk8biHZIoLjnkJ20It6w3141 FAsLx8+ow97k/UcZv4JbgSLhyWJiP9L7t+kTc6DipT41thuZyQHSrKw3Q/RIEXR6xIsy 8fqkLnsc/+9U6DQ7z7ijXlRracPF3TcSgsS34SspyrUx7CfGWo+y67ZDIYfjoArknZ8w CYh0qFhjmfH/uTuv6KMdOQlwNlMC4tMF/OTMXxwVjzywp3n75ILH0Q2fyHFqO7WeXJtu kqxg== X-Gm-Message-State: AOAM5313MFZ57gNHou9ysZXNYNgWrZ/y01HRWblCdgPHtHVYSY80jpGd snTTtlVwB1srvN1nNTf18Q== X-Google-Smtp-Source: ABdhPJx8UyDZ2WZB8MOoIL+fk0x6mt0VLjgCkFCe36079B8wXfu/qSvvf52TK/tAtu/bv25UkC+6Yg== X-Received: by 2002:a9d:3461:: with SMTP id v88mr15323231otb.40.1605902627605; Fri, 20 Nov 2020 12:03:47 -0800 (PST) Received: from xps15 (24-155-109-49.dyn.grandenetworks.net. [24.155.109.49]) by smtp.gmail.com with ESMTPSA id v5sm2048811oob.40.2020.11.20.12.03.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Nov 2020 12:03:46 -0800 (PST) Received: (nullmailer pid 1658486 invoked by uid 1000); Fri, 20 Nov 2020 20:03:45 -0000 Date: Fri, 20 Nov 2020 14:03:45 -0600 From: Rob Herring To: Will Deacon , Mark Rutland Cc: Catalin Marinas , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Jiri Olsa , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Alexander Shishkin , Namhyung Kim , Raphael Gault , Jonathan Cameron , Ian Rogers , honnappa.nagarahalli@arm.com, Itaru Kitayama Subject: Re: [PATCH v4 2/9] arm64: perf: Enable pmu counter direct access for perf event on armv8 Message-ID: <20201120200345.GA1194400@robh.at.kernel.org> References: <20201001140116.651970-1-robh@kernel.org> <20201001140116.651970-3-robh@kernel.org> <20201113180633.GE44988@C02TD0UTHF1T.local> <20201119191515.GA4906@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201119191515.GA4906@willie-the-truck> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 19, 2020 at 07:15:15PM +0000, Will Deacon wrote: > On Fri, Nov 13, 2020 at 06:06:33PM +0000, Mark Rutland wrote: > > On Thu, Oct 01, 2020 at 09:01:09AM -0500, Rob Herring wrote: > > > +static void armv8pmu_event_unmapped(struct perf_event *event, struct mm_struct *mm) > > > +{ > > > + if (!(event->hw.flags & ARMPMU_EL0_RD_CNTR)) > > > + return; > > > + > > > + if (atomic_dec_and_test(&mm->context.pmu_direct_access)) > > > + on_each_cpu_mask(mm_cpumask(mm), refresh_pmuserenr, NULL, 1); > > > +} > > > > I didn't think we kept our mm_cpumask() up-to-date in all cases on > > arm64, so I'm not sure we can use it like this. > > > > Will, can you confirm either way? > > We don't update mm_cpumask() as the cost of the atomic showed up in some > benchmarks I did years ago and we've never had any need for the thing anyway > because out TLB invalidation is one or all. That's good because we're also passing NULL instead of mm which would crash. So it must be more than it's not up to date, but it's always 0. It looks like event_mapped on x86 uses mm_cpumask(mm) which I guess was dropped when copying this code as it didn't work... For reference, the x86 version of this originated in commit 7911d3f7af14a6. I'm not clear on why we need to update pmuserenr_el0 here anyways. To get here userspace has to mmap the event and then unmmap it. If we did nothing, then counter accesses would not fault until the next context switch. If you all have any ideas, I'm all ears. I'm not a scheduler nor perf hacker. ;) Rob