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.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 3069CC433E0 for ; Thu, 7 Jan 2021 00:20:47 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 C804620784 for ; Thu, 7 Jan 2021 00:20:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C804620784 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Ze0OmX6joL7wKXkNgO3cT42dcBy7S5mm+MEsCOosr6c=; b=bmBAy3eVZUspeggbEiBFfZiiq kJEKN+fGAaHBiv5amAmK5Qs4M26Z4gfTy9nDHCFiOc2R/IXnrzmlFx1AH1VLvlNUabgki2o/N8uw9 C8l0LEtLs0sYviQGo26ZMV1RW1aX6vhby22zJxptlsOrTCvOnvEn7MBjqX/TDBj1bC13D0aAxN9uF VB3XGdKPNEHVMXVqGit5EEHkAqRmimVypoDK3Zc2SbczfF1aJqEyfRRqS3G+1W2E6ZWAEeTuQv7Uh ywIx0wyIJyaT19BjnZPqnCWsoEQp+/pUFqtvKIjAdlBDZBcNbEYFZyZWy4gc97CLzYl4vHAGvxaD9 w0d/65aSg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kxJ03-0008WE-N3; Thu, 07 Jan 2021 00:17:59 +0000 Received: from mail-io1-f48.google.com ([209.85.166.48]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kxJ01-0008Vb-Eo for linux-arm-kernel@lists.infradead.org; Thu, 07 Jan 2021 00:17:58 +0000 Received: by mail-io1-f48.google.com with SMTP id i18so4527337ioa.1 for ; Wed, 06 Jan 2021 16:17:54 -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=FgrYw6CEb+ECs/AKbPpiobOC3t4eF7B8rST9fAhMs0c=; b=kpNjFGMHY1Pk7PjlaQpujjZUNQFJ/Y3ik3mgKz9+aqikwgZcNRzv9NqndOC7AWV+ep CXtsAOCsEVP3T5g6nJ31BrLNy9RUmmeUupqZ26pMV3V7uu7PivjbO/jZ9esw2yG678kk 5Eeq+1E6qZCzLJmXpOJK4BuZNrlAvO8GnwPTzEDoq9Q9xy8aHMRggRP/oTgCnMaZ5l28 UTF4Tst14H2B+9zVjEUf0j0H1B3Vola+rJ6XXagoSDpl1ZTcmXo7awG39KKwNaBt4zUx yBl3dvfVXUHfxlZ976PhD/n+BuAh5Sn19LX06BTMsrFRpdsDzhs85axv6921V4a/K1e+ /awQ== X-Gm-Message-State: AOAM5309PZAWZmxCrZNhh8agsbzd6W01lTVNoSuuQ+yltEiSYwJvsfNY 45Cdx3wdik7j+ToiBDp1pQ== X-Google-Smtp-Source: ABdhPJxSur2zxumivzuWwijJd/lRHpCe+8V1iSy3qb8ch5Av6rofjze2u3I3BfbAV5wiNhxM6zF5NQ== X-Received: by 2002:a02:5148:: with SMTP id s69mr5874646jaa.8.1609978673944; Wed, 06 Jan 2021 16:17:53 -0800 (PST) Received: from robh.at.kernel.org ([64.188.179.253]) by smtp.gmail.com with ESMTPSA id y3sm3201908ilc.2.2021.01.06.16.17.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Jan 2021 16:17:52 -0800 (PST) Received: (nullmailer pid 3617650 invoked by uid 1000); Thu, 07 Jan 2021 00:17:50 -0000 Date: Wed, 6 Jan 2021 17:17:50 -0700 From: Rob Herring To: Will Deacon , Mark Rutland Subject: Re: [PATCH v4 2/9] arm64: perf: Enable pmu counter direct access for perf event on armv8 Message-ID: <20210107001750.GA2204700@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> <20201120200345.GA1194400@robh.at.kernel.org> <20201202145747.GA2381290@robh.at.kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201202145747.GA2381290@robh.at.kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210106_191757_511605_B02C98F6 X-CRM114-Status: GOOD ( 31.20 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Ian Rogers , Peter Zijlstra , Catalin Marinas , linux-kernel@vger.kernel.org, Arnaldo Carvalho de Melo , Alexander Shishkin , Raphael Gault , Ingo Molnar , honnappa.nagarahalli@arm.com, Jonathan Cameron , Namhyung Kim , Itaru Kitayama , Jiri Olsa , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Dec 02, 2020 at 07:57:47AM -0700, Rob Herring wrote: > On Fri, Nov 20, 2020 at 02:03:45PM -0600, Rob Herring wrote: > > 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); > > > > > +} Bump on this again... :) > > > > > > > > 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. Okay, I've come up with a test case where I can trigger this. It's a bit convoluted IMO where the thread doing the mmap is different thread from reading the counter. Seems like it would be better if we just disabled user access if we're not doing calling thread monitoring. We could always loosen that restriction later. x86 OTOH was wide open with access globally enabled and this hunk of code was part of restricting it some. > > > > If you all have any ideas, I'm all ears. I'm not a scheduler nor perf > > hacker. ;) > > Mark, Will, any thoughts on this? Any reason, this would not work: static void refresh_pmuserenr(void *mm) { if (mm == current->active_mm) perf_switch_user_access(mm); } The downside is we'd be doing an IPI on *all* cores for a PMU, not just the ones in mm_cpumask() (if that was accurate). But this isn't a fast path. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel